Table of Contents
Ten Years on Ubuntu 16.04 — and Then Reality Hit
When developer Antonio Croci decided to finally shut down his blog’s server, the uptime counter read 1,491 days. That is more than four years of continuous operation without a single reboot. It is the sort of figure that can make a server administrator proud—and then uneasy.
The machine was still running Ubuntu 16.04 LTS, on a VPS that had become a ten-year-old part of the setup. Ubuntu 16.04 fell out of Canonical’s standard support window in 2019 and reached end-of-life in April 2021. By the time Croci moved on, it had been unsupported for five years. The server had not failed loudly. It had simply continued doing its job long after the operating system beneath it stopped receiving the attention a public-facing machine requires.
That distinction matters. Long uptime can signal stability, but it can also mean that no one has revisited assumptions that were safe when the server was built. A small blog does not usually have a security operations team reviewing advisories, testing patches, rotating credentials, and checking every exposed service. It has one person who is busy, a site that appears to load normally, and a machine that has given no obvious reason to touch it.
After end-of-life, the apt package repositories go dark: no more security patches, no more updates, no more fixes for whatever vulnerabilities surface next. The server was, by any reasonable measure, flying without instruments. Croci admits nothing bad ever happened, but he also acknowledges that this was partly luck.
Anyone who has managed WordPress sites for long enough has seen how quietly a compromise can unfold. Croci’s horror story involves a blog that was stuffed with hidden casino and gambling links after an old VPS was compromised. That kind of spam is visible eventually, if someone checks search results or page source closely enough. Other outcomes are less forgiving: credential theft, ransomware, or a machine quietly absorbed into a botnet. The point is not that every unsupported server will be breached. It is that an unsupported server loses the routine maintenance path intended to reduce that risk.
There are still thousands of Ubuntu 16.04 instances online, many likely attached to personal projects and small business sites where nobody is following security bulletins. Canonical’s official release cycle documentation says standard LTS support runs for five years. That is a generous window compared with many software products, but it is still a deadline. “It still works” and “it is still safe” are not the same sentence, particularly when the machine is reachable from the public internet.
The useful lesson here is not that Ubuntu failed Croci. Ubuntu 16.04 had a long life, and the server’s 1,491 days of uninterrupted operation suggest a system that was dependable in the narrow sense. The failure was operational inertia. An old server can remain functional enough to postpone the very work that needs doing: rebuilding, documenting dependencies, testing restores, and deciding what the site actually needs from its hosting stack.
FreeBSD Migration: Why Not Just Upgrade to Ubuntu 24.04?
The obvious move would have been a straight upgrade: wipe the old Droplet, spin up a fresh Ubuntu 22.04 or 24.04 LTS instance, reinstall nginx, and call it done in an afternoon. For many site owners, that remains the sensible choice. Familiarity is not a vice when it means faster recovery, easier maintenance, and fewer surprises.
Croci chose not to do that. His FreeBSD migration was driven partly by curiosity—he had been following BSD content for a while and wanted real-world experience with it—but there was a technical argument underneath the experiment. Instead of treating a required rebuild as a chore, he used it to reconsider the layout of the server itself.
FreeBSD occupies a distinct position in the server operating system landscape. It is not Linux and shares no kernel lineage with Ubuntu, Debian, or the major Linux distributions. It descends from the original Berkeley Software Distribution Unix work. That historical separation does not automatically make it better for every workload, nor does it erase the learning curve for someone used to Linux tools and conventions. It does mean that a migration asks different questions about packaging, service management, networking, storage, and isolation.
Jails make isolation a default design choice
The most compelling part of Croci’s setup is FreeBSD Jails. Jails offer container-like isolation that predates Docker by decades, giving each site its own sandboxed environment. The comparison should not be stretched too far: Docker became popular through a broader application-packaging workflow and a large ecosystem built around image distribution. But the practical instinct behind both approaches is familiar. Separate workloads so that one site’s dependencies, configuration mistakes, or compromise do not automatically become every other site’s problem.
For a person hosting multiple sites, that separation can be more valuable than a long list of features. A web stack is rarely static. One site may need a different runtime, another may need an older dependency, and a third may be retired but still kept online. Putting everything directly on one host can turn ordinary updates into a fragile shared exercise. Jails create boundaries without requiring each site to become an entirely separate VPS.
Isolation is not magic security. It still depends on disciplined configuration, prompt updates, sensible access controls, and backups that can actually be restored. But it is a useful way to limit the blast radius. That is especially relevant after an experience involving hidden gambling links: the problem with a compromise is not only what gets altered, but how far the alteration can spread before it is noticed.
Snapshots change the backup calculation
Storage was another reason the FreeBSD migration made sense. ZFS snapshots replace expensive provider backups, adding serious filesystem resilience without extra monthly fees. A snapshot is not a substitute for every kind of backup strategy—especially if a failure affects the storage itself or an administrator needs recovery outside the server—but it gives an operator a fast way to preserve a known state before changes and to recover from many everyday mistakes.
That matters on a small server because the common failures are often mundane. A bad update, an accidental deletion, a broken configuration, or a failed deployment can be more likely than a dramatic infrastructure disaster. Provider backups are convenient, but they can become another recurring charge that feels difficult to justify for a modest site. ZFS snapshots put more of that recovery capability into the server’s own operating model.
The financial result was direct. The move cut hosting costs by more than half, from DigitalOcean at $13 per month to Hetzner at under €6. Lower cost alone is not proof of a better architecture; the cheapest server is a poor bargain if it is harder to maintain or recover. In this case, though, Croci paired the reduction with a newer operating system, Jails for isolation, and ZFS snapshots for resilience. That is a stronger argument than simply chasing a lower monthly bill.
There is also a broader point for anyone nursing along an aging VPS. A migration is disruptive, and a straightforward Ubuntu rebuild may still be the right answer. But a forced refresh can reveal how much of the old setup existed merely because it had always existed. Croci’s FreeBSD move did not turn an unsupported Ubuntu 16.04 server into a cautionary tale because it was old. It did so because the server had been allowed to outlive its maintenance plan. The replacement matters because it gives that plan a clearer shape.
