DEV Community: Zerolock

How I replaced WhatsApp and phone calls at a construction company using Mattermost

Mišo Oroz — Tue, 27 Oct 2026 09:34:29 +0000

At a construction company where I worked as IT manager, communication was fragmented across three channels that never talked to each other.

Seven people in the office. Around twenty workers and laborers across active construction sites, four or five on any given site at a time. Messages on personal WhatsApp numbers. Phone calls. The occasional email nobody read in time. Site photos sent to random personal chats. The office never knew what was happening on site unless someone picked up the phone.

The standard answer would have been Slack or Microsoft Teams. I went with Mattermost.

Why Mattermost

Three reasons.

Self-hosted. The company's data, site photos, project updates, internal decisions, stays on a server I control. Not on Slack's infrastructure, not on Microsoft's. For a small business that was a deliberate choice, not a compliance checkbox.

One nuance worth knowing: push notifications for the official mobile apps are relayed through Mattermost's hosted push service, which forwards them to Apple and Google. The message content stays on my server, the notification metadata does not. Fully self-hosted push means compiling your own mobile apps with your own push proxy, which was more complexity than a company of this size needed. For this deployment, the trade-off was acceptable.

The mobile app works. Construction workers are not going to open a browser on their phone. The Mattermost Android app is fast and sends push notifications reliably. That was non-negotiable.

The desktop client behaves well on KDE Plasma. Tray icon works, notifications integrate cleanly, no visual glitches. Relevant because KDE is the Linux desktop I deploy.

The deployment

I installed Mattermost on an existing VPS that already hosted other internal services, with PostgreSQL as the database and Nginx in front for TLS. The official docs cover this well. What mattered more was what came after the install.

I created the team and built a minimal channel structure: one general channel, one per active project, one for the office, one for site updates.

I kept it flat on purpose. Over-organizing before people start using the tool is a waste of time.

Training the office and the site supervisors

The office staff took about thirty minutes each. Channels instead of group chats clicked quickly once I showed one real example.

The workers took longer, not because the app was difficult, but because structured communication was new to them. What worked was framing it simply: the work WhatsApp, but owned by the company, and nothing gets lost.

I ran one group session on site with the supervisors' phones. Showed them how to post a photo to the right project channel. They then handled it with their own crews. That was most of the training.

Then I left them alone.

What actually changed

Before Mattermost, the only way to know what was happening on site was a phone call. The office would ask, someone would answer, information would get lost in translation.

After the deployment, the geometra (site surveyor) could open the project channel and see what the capocantiere (site foreman) had posted an hour ago. The owner could check site progress without calling anyone. The office had context when clients called with questions. Everyone was looking at the same information at the same time.

Nobody asked for this explicitly. It emerged from having one place where site updates actually landed.

What happened after I stopped managing it

A few weeks in I checked the channels. The team had reorganized things themselves. Created channels I hadn't set up. Developed their own conventions. One site supervisor started pinning important updates so the office could find them later.

I had not asked for any of that.

If the tool is solid and the initial training is honest, people adapt it to their actual workflow without hand-holding.

Two things I'd tell anyone deploying this

Keep the initial channel structure minimal. Three or four channels maximum at the start. Let the team build it out once they understand how they actually communicate.

Plan for storage before you go live. Construction sites generate a lot of photos. Twenty workers with phones and something visual about their work will fill a disk faster than you expect. Size the VPS accordingly, set file size limits from day one, and decide early what happens to old project channels: archive them, keep the files, and make sure your backup covers both the database and the file store.

I no longer work at that company. The setup stayed, which is the part I care about. I carry the same approach into my current work at Zerolock, where Mattermost is part of the standard stack I deploy for clients who need internal communication without handing data to third-party platforms.

zerolock.it

KDE Plasma crashes after system update on Kubuntu 26.04: fontconfig race condition fix

Mišo Oroz — Wed, 23 Sep 2026 14:35:37 +0000

Last week I updated a Kubuntu 26.04 LTS workstation and came back to a broken desktop. KDE Plasma would start, the desktop would flash for a second, then disappear. plasmashell kept crashing in a loop. The machine was otherwise fine: Konsole worked, Firefox worked, Thunderbird worked, the system was responsive. Just no desktop.

This is what I found and how I fixed it permanently.

What was happening

The crash was a SIGSEGV in plasmashell, repeating every few seconds with Failed with result 'core-dump' in the service logs. After digging into the stack trace, the culprit was fontconfig.

The root cause is a race condition at login. When you log in after a system update that touches font packages, plasmashell starts reading the font cache at the same time something else triggers its regeneration. fontconfig ends up writing a new cache while plasmashell is already reading the old one, which causes a segfault inside FcCharSetHasChar.

It is a timing issue, which is why it does not happen on every update and why a simple restart sometimes appears to fix it temporarily.

Diagnosing

Before touching anything, confirm the crash is what I described:

coredumpctl list --since today --no-pager

You should see plasmashell crashes. Then read the stack:

coredumpctl info plasmashell --no-pager | grep -A40 "Stack trace of thread"

Look for FcCharSetHasChar in the trace. If it is there, you have the same issue.

Also worth checking the session log:

journalctl --user -b --no-pager -p warning | grep -iE "plasmashell|fontconfig" | tail -20

Temporary fix

This gets the desktop back immediately without a reboot:

rm -rf ~/.cache/fontconfig
sudo rm -rf /var/cache/fontconfig/*
sudo fc-cache -r -f
fc-cache -r -f
systemctl --user reset-failed plasma-plasmashell
systemctl --user restart plasma-plasmashell

The desktop should come back within a few seconds. This works until the next reboot, at which point the race condition can happen again.

Permanent fix

The real solution is to force a font cache regeneration before plasmashell starts. You do this with a systemd drop-in that adds an ExecStartPre directive to the plasmashell service:

mkdir -p ~/.config/systemd/user/plasma-plasmashell.service.d

Then create the drop-in file:

cat > ~/.config/systemd/user/plasma-plasmashell.service.d/fontcache.conf << 'EOF'
[Service]
ExecStartPre=/usr/bin/fc-cache -f
EOF

Reload systemd and reboot:

systemctl --user daemon-reload
sudo reboot

After login, verify it worked:

systemctl --user status plasma-plasmashell | head -10

You want to see this in the output:

Process: ExecStartPre=/usr/bin/fc-cache -f (code=exited, status=0/SUCCESS)
Active: active (running)

If you see that, the drop-in is working and the font cache is being regenerated before plasmashell touches it on every boot.

Why this works

The systemd drop-in ensures fc-cache completes before plasmashell starts. No race, no partial file reads, no segfault. It adds a second or two to login time, which is a reasonable trade for a stable desktop.

The drop-in survives updates because it lives in your user config directory, not in the system service file. If a future KDE or fontconfig update changes the timing behavior, you can simply remove the drop-in and check if the issue is gone.

Environment

Kubuntu 26.04 LTS, KDE Plasma 6.6.6, kernel 7.0.0-34, Intel Raptor Lake i915. I deploy Kubuntu 26.04 on client workstations and hit this after a routine update. The fix has held across multiple reboots and subsequent updates.

If you are seeing something similar but the stack trace does not mention fontconfig, this drop-in will not help. The crash is something else. Check the coredumpctl output carefully before applying anything.

zerolock.it

WireGuard VPN for Production: The Exact Setup I Deploy for Small Businesses

Mišo Oroz — Tue, 15 Sep 2026 09:11:45 +0000

WireGuard is the VPN I deploy for every small business I migrate to Linux. Not because it is trendy, but because it is the most honest piece of networking software I have worked with in fifteen years.

In 2026, WireGuard is the default VPN protocol for a reason: it is in the mainline Linux kernel since version 5.6, independently audited, and faster than OpenVPN on the same hardware. For small businesses this means no kernel modules to maintain, no CVE backlog, and no performance complaints.

The entire trust model fits in a single config file. When something breaks, you can audit it in minutes. That matters at 8am on a Monday when a client cannot connect and you need to diagnose fast.

This is not a theoretical walkthrough. This is exactly what I deploy in production.

Before you start

Server with static public IP
UDP 51820 open on server firewall
SSH access to the server
Client machine with working internet connection
A clear decision on whether all traffic routes through the tunnel or only the internal network (more on this below)
A backup access plan if the tunnel breaks (physical access, out-of-band SSH, etc.)

Why WireGuard specifically

The WireGuard codebase is roughly 4,000 lines. OpenVPN's core daemon is closer to 70,000. This is not a marketing detail. Smaller codebase means smaller attack surface, faster patching, and a security posture you can actually reason about.

WireGuard has been independently audited. The Cure53 audit in 2021 and the Trail of Bits review found no critical vulnerabilities. OpenVPN has also been audited, but its larger codebase makes comprehensive auditing more time-consuming and leaves more surface area for potential issues.

I evaluated three options before standardizing on WireGuard:

OpenVPN: mature, flexible, but complex. Requires certificate management, has a larger attack surface, and is noticeably slower on low-end hardware.

IPsec/IKEv2: fast and secure, but configuration is opaque. Debugging failures often requires deep protocol knowledge.

WireGuard: minimal, audited, fast. The trade-off is manual key management, which is acceptable for teams under 20 people.

For small businesses that cannot afford enterprise security teams, choosing audited software with a minimal codebase is one of the few concrete security decisions they can make.

What you need

A Linux server you control. In my case a VPS hosted in Italy, running Debian 12. A static IP on the server side. A client machine running Linux, in most cases Kubuntu 26.04 LTS.

I use a VPS for the relay in most deployments because it gives clients a stable public IP without managing physical hardware at the office. For businesses with an on-premise server already in place, running WireGuard directly on that machine works equally well. The config is identical.

Debian 12 is the default for server deployments: predictable release cycle, five years of security updates, no surprises. I avoid rolling releases on anything client-facing.

WireGuard uses public key cryptography. Each peer generates a key pair. You exchange public keys. No certificates, no certificate authorities, no complexity that lives outside the config file.

Server setup

Install WireGuard:

apt install wireguard

Generate the server key pair. Set permissions before the key is used:

wg genkey > /etc/wireguard/privatekey
chmod 600 /etc/wireguard/privatekey
wg pubkey < /etc/wireguard/privatekey > /etc/wireguard/publickey

Create the server configuration at /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = <server_private_key>
Address = 10.0.0.1/24
ListenPort = 51820
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o <interface> -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o <interface> -j MASQUERADE

[Peer]
PublicKey = <client_public_key>
AllowedIPs = 10.0.0.2/32

Replace <interface> with your actual network interface name. On Debian 12 modern installs this is typically ens3, enp1s0, or similar. Check with ip link before editing the config. Almost never eth0.

Why 10.0.0.0/24? This is RFC 1918 private space, unlikely to conflict with most office networks. I use 10.0.0.1 for the server and increment client IPs from 10.0.0.2. If your office already uses 10.0.0.0/24, choose a different range such as 10.100.0.0/24 to avoid routing conflicts.

On the /32 for each peer: this tells WireGuard that this specific public key is only allowed to use the IP 10.0.0.2. Each peer must have its own /32 entry. Without it, a compromised client could potentially spoof other addresses on the tunnel.

Note on cloud providers: if you use a VPS with a cloud security group (Hetzner, DigitalOcean, AWS), open UDP 51820 in the security group rather than via iptables. The PostUp rules above handle forwarding and NAT, not port access itself.

If your server has IPv6 enabled, which is common on modern VPS, add ip6tables rules as well:

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o <interface> -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -A FORWARD -o wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o <interface> -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o <interface> -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -D FORWARD -o wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o <interface> -j MASQUERADE

Enable IP forwarding:

echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.conf
sysctl -p

Enable and start:

systemctl enable --now wg-quick@wg0

Client setup

Install WireGuard and openresolv:

apt install wireguard openresolv

Generate client key pair:

wg genkey > /etc/wireguard/privatekey
chmod 600 /etc/wireguard/privatekey
wg pubkey < /etc/wireguard/privatekey > /etc/wireguard/publickey

Create /etc/wireguard/wg0.conf on the client:

[Interface]
PrivateKey = <client_private_key>
Address = 10.0.0.2/32
DNS = 1.1.1.1

[Peer]
PublicKey = <server_public_key>
Endpoint = <server_public_ip>:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Why /32 on the client? The client is a single host, not a subnet. Using /32 is semantically correct and avoids confusion when adding more clients later. The /24 on the server interface is correct because it represents the entire tunnel network.

0.0.0.0/0, ::/0 routes all traffic through the VPN, including IPv6. If you only need access to the internal network without routing everything, use the specific subnet instead, for example 10.0.0.0/24. Understand what you are routing before you route it.

PersistentKeepalive = 25 sends a keepalive every 25 seconds. Required when the client is behind NAT, which is almost always the case for small business remote workers. Without it the NAT mapping expires and the tunnel silently drops.

Enable and start:

systemctl enable --now wg-quick@wg0

Verify the tunnel:

wg show
ping 10.0.0.1

wg show confirms the handshake happened. ping 10.0.0.1 confirms the tunnel carries traffic. Both should work before you call it done.

DNS on Kubuntu 26.04 with systemd-resolved

Kubuntu 26.04 uses systemd-resolved by default. The DNS = directive in wg0.conf works correctly with systemd-resolved, but you must ensure /etc/resolv.conf points to the stub resolver:

ls -l /etc/resolv.conf

Expected output:

/etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

If it points elsewhere, fix it:

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

Bring up the tunnel and verify DNS is routing correctly:

resolvectl status wg0

You should see your configured DNS listed under the wg0 interface.

Verify no DNS leaks

A DNS leak means your DNS queries are going outside the tunnel, exposing which domains you visit even if the traffic itself is encrypted. After bringing up the tunnel, verify:

dig +short myip.opendns.com @resolver1.opendns.com

This should return your VPN server's public IP, not your client's real IP. If it returns your real IP, DNS is leaking.

Also check for IPv6 leaks:

curl -6 ifconfig.co

If this returns an IP, IPv6 traffic is not going through the tunnel. Either disable IPv6 on the client or ensure ::/0 is in AllowedIPs and add an IPv6 DNS server: DNS = 1.1.1.1, 2606:4700:4700::1111.

Key management

WireGuard has no built-in key rotation. When an employee leaves or a device is compromised, you must manually remove the [Peer] block from the server config and redistribute new keys.

My workflow for small businesses: I keep a simple spreadsheet with peer name (for example "alice-laptop"), public key copied from /etc/wireguard/publickey, device owner, creation date, and last rotation date. Rotate keys every 12 to 18 months as standard practice. If a device is lost, revoke immediately: remove the [Peer] block, restart WireGuard, and generate new keys for the affected client.

This manual process is a trade-off: you gain simplicity and auditability, but lose automated lifecycle management. For teams under 20 people it is acceptable. Beyond that, consider a WireGuard management layer like Netmaker or Headscale.

Monitoring and troubleshooting

Check handshake age — should be under two minutes on an active connection:

wg show | grep "latest handshake"

Watch live traffic through the tunnel:

watch -n1 'wg show | grep transfer'

For proactive monitoring I use a simple cron job that pings the tunnel IP every 5 minutes and logs failures:

*/5 * * * * ping -c1 10.0.0.1 || logger "WireGuard tunnel down"

If the tunnel drops:

Check logs: journalctl -u wg-quick@wg0
Verify the port is reachable: nc -vzu <server_ip> 51820
Confirm PersistentKeepalive = 25 is set on the client
Restart the tunnel: systemctl restart wg-quick@wg0

Appendix: Kubuntu 26.04 and Wayland

Kubuntu 26.04 uses Wayland by default. This does not affect WireGuard itself, but it breaks X11-based remote desktop tools. For full remote access setups I pair WireGuard with a self-hosted RustDesk relay, which handles Wayland correctly. On Kubuntu 24.04, which still uses X11, standard remote desktop tools work without this additional step. RustDesk with a self-hosted relay is outside the scope of this guide but worth knowing before you commit to a 26.04 deployment for remote workers.

Final notes

I have been running this setup across multiple client deployments since early 2026. No security incidents, no unexplained drops. WireGuard's simplicity is its strength: when something breaks, you can read the entire config and understand it in minutes.

For small businesses migrating to Linux, this is the VPN layer I standardize on. And if a client or an auditor ever asks why I chose it, I can explain every line of the config. That is not something I could say about most alternatives.

zerolock.it

Nextcloud vs Google Drive: a practical comparison for small business migrations

Mišo Oroz — Sun, 06 Sep 2026 14:20:24 +0000

I've been migrating small businesses in northern Italy from Google Workspace and Microsoft 365 to open source stacks for a while now. One of the first questions I always get is: "What about file storage? We use Google Drive for everything."

Fair question. Let me give you an honest answer, not a sales pitch.

What we're actually comparing

When I say Google Drive in a business context, I mean the full Google Workspace package: Drive, Docs, Sheets, Gmail, Meet. It's a coherent platform that works well. I'm not going to pretend otherwise.

Nextcloud is a self-hosted (or managed-hosted) file sync and collaboration platform. Out of the box it handles file storage, sharing, and sync across devices. With apps you can add calendar, contacts, talk (video calls), and collaborative document editing via Nextcloud Office (built on Collabora).

So the comparison isn't just "where do files live." It's about how your client's business actually runs day to day.

The real differences that matter

Data location and sovereignty

With Google Drive, your files live on Google's infrastructure. Full stop. For most small businesses this isn't a problem until it is: GDPR compliance questions, a client contract that requires data to stay in Italy, or a sector with specific regulations (legal, medical, financial).

With Nextcloud you choose where data lives. I typically set up clients on Italian or Swiss-based infrastructure, choosing providers that keep data within EU jurisdiction. The client owns the data, period.

This matters more than people realize. I've had clients lose access to their Google Workspace because of billing issues during a holiday weekend. With self-hosted infrastructure, you control the keys.

Cost structure

Google Workspace Business Starter runs around 6.80 euros per user per month at the time of writing (check current pricing on their site as this changes). For a team of 8 that's around 653 euros per year, just for the base tier. Storage limits apply at 30 GB pooled per user, and many teams end up on a higher plan within a year.

Nextcloud itself is open source and free. You pay for hosting. A decent VPS with enough storage for a small team costs 15 to 30 euros per month, depending on specs and provider. For 8 users that's 180 to 360 euros per year, with no per-user licensing.

The math is straightforward. The savings compound over time.

Feature parity

This is where people get nervous. Let me be direct: Nextcloud is not Google Drive. Some things work differently, some things work better, some things are more manual.

File sync across devices works well. The desktop clients for Linux, Windows, and macOS are stable. Mobile apps exist for Android and iOS.

Collaborative editing works if you install Nextcloud Office. It's not as smooth as Google Docs in my experience, but it's functional for most business use cases. If your team lives inside documents all day, evaluate this carefully before committing.

Search is decent but not Google-level. For a team that stores lots of documents and searches constantly, this is worth testing with real data before the migration.

Sharing links, permissions, versioning: all there and well implemented.

Administration overhead

This is the honest part. Google Workspace has zero admin overhead for the IT person. You click, it works, Google handles updates, security patches, and uptime.

Nextcloud requires someone to handle updates, monitor the instance, and occasionally deal with issues. If that someone is you (the IT consultant), you need to factor this into your service contract. If it's supposed to be the client on their own, think carefully.

For the clients I manage this is part of the monthly support I provide. It's not heavy lifting, but it's not zero either.

When I recommend Nextcloud

I push for Nextcloud when the client has 2 to 20 users with straightforward storage and sharing needs and no heavy real-time collaboration on complex documents.

There's a compliance or sovereignty angle that matters. Legal practices, small financial advisors, healthcare adjacent businesses. Anything where "your data is on Google's servers" is a problem worth solving.

The client wants predictable costs with no per-user licensing that grows as they hire.

They're already moving to a Linux-based workstation setup, so the open source philosophy is consistent across the stack.

When I don't

If the client's workflow is deeply integrated into Google Workspace, a migration is painful and the value is lower. At Zerolock we've walked away from a couple of these rather than force a migration that would hurt the client more than help them. Heavy Docs and Sheets collaboration, Gmail filtering built into daily operations, Google Meet for all external calls: these are signals to evaluate carefully before committing to a switch.

Same with shops that use Teams heavily for video and internal communication. The Nextcloud Talk feature is improving but it's not Teams, and if video collaboration is critical, that matters.

The migration process in practice

For a typical 5 to 8 person team, here's roughly how it goes.

Set up the Nextcloud instance. I use Docker on a VPS, behind a reverse proxy, with automated backups to a separate location.

Migrate existing files from Google Drive using rclone. It handles the OAuth flow cleanly and can do incremental syncs during the transition period.

Install and configure desktop clients on each workstation. On Linux (Kubuntu in my case) this is straightforward via the official package.

Train the team. Usually half a day. Most people adapt quickly because the core experience, folder, file, share, is familiar.

Run parallel for two to four weeks. Both systems active, with the team gradually moving their work to Nextcloud. Then cut over.

The hardest part is usually email. If they're leaving Gmail too, that's a separate migration with Thunderbird or a webmail setup. But that's a different article.

One thing I'd add

I've found that clients are more comfortable with Nextcloud than they expect, mostly because it looks and behaves like a normal file system. The "everything is a proprietary document format" model confuses some users who just want to store a PDF and find it later. Nextcloud handles that interaction more naturally.

It's not the right tool for every situation. But for a lot of small businesses that don't need the full cloud suite and do care about where their data lives, it's a solid, honest choice.

If you're doing similar migrations and have questions about the setup, happy to compare notes.

zerolock.it

How we migrated an Italian logistics company from Windows to Linux: a real case study

Mišo Oroz — Wed, 02 Sep 2026 14:34:47 +0000

In early 2026 I migrated a logistics and transport company in Bergamo, Italy from a fully proprietary setup to Linux and open source. Five workstations, five employees, zero technical background on their side. Here is what we did, what happened, and what I learned.

The starting point

The company was running Windows on every workstation, Microsoft Office for documents, a third-party antivirus renewed annually, and an external IT technician called in every time something broke. They had no internal IT knowledge and no interest in acquiring any. They just wanted things to work.

Their main pain points were slow machines, frequent crashes after Windows updates, and a recurring bill that kept growing without any visible improvement.

What we installed

I replaced everything with a fully open source stack:

Kubuntu as the operating system on all five workstations
LibreOffice in place of Microsoft Office
Thunderbird for email
Nextcloud for file sharing and internal document management, self-hosted on a server in Italy
Mattermost for internal team communication
pfSense as the network firewall
WireGuard for VPN access
Automated encrypted backups running nightly

Total recurring licence cost after migration: zero.

The migration process

The full migration took approximately one week. I configured everything on a test machine first, validated all workflows with the team, then rolled out workstation by workstation during off-hours to avoid interruptions.

The biggest challenge was not technical. It was psychological. People are used to what they know. I spent as much time sitting with each employee and showing them that LibreOffice opens their Word files and Nextcloud works like Google Drive as I did on the actual technical setup.

After three days they stopped asking about Windows.

Results after six months

Six months in, the company has not called me for a single ordinary technical issue. The machines are faster. Updates do not break anything. There have been zero security incidents.

The most concrete result: each employee recovered roughly one hour per day that was previously lost to slowdowns, crashes and waiting for the external technician. On five people that is five hours a day returned to productive work.

Licence costs are gone. The infrastructure belongs to them, not to a vendor.

Why this matters beyond one company

Most Italian SMEs are in the same situation. They pay recurring fees for software they do not own, store data on foreign servers subject to the US Cloud Act, and depend on vendors who can change the rules at any time.

Linux and open source infrastructure is not experimental. It is mature, stable, and ready for business use. The barrier is not technical. It is awareness.

I wrote the Zerolock Manifesto (https://zerolock.org) on exactly this topic. If you are working on similar migrations or have questions about the stack, I am happy to discuss in the comments.