Every growing platform or SaaS company hits the same choice. Do we stay on virtualized infrastructure, which is easy to provision and resize, or move onto hardware we actually control, but will ultimately need to maintain (and retire)? It's a bit like renting or owning. Like most people, we stayed on the first option for a long time, but this week was moving week. We took Canner's entire build and hosting platform off a fleet of virtualized servers, and migrated onto a dedicated server we manage — with customers still deploying the whole time.
Why VPS made sense at the start
Virtualized servers were the right call for most of the platform's life. Fast to provision, easy to change, someone else deals with it. The cost showed up later, and not actually on the bottom line. The real drag is the other tenants you can't see, mystery CPU allocation, and unpredictable performance at cron times and other load-bearing windows. On top of that, some errors and OS-level isolation mean you simply don't get a full read on the hardware you're using.
A missing security piece of the story
Part of how we actually isolate our customers' builds relies on kernel-level network restrictions — the OS blocking a process from reaching what it shouldn't, meaning you don't just "trust" application code to behave. You assume it will fail or be broken. During the post-migration verification builds, one build failed to resolve a domain mid-install. Another failed to reach our database proxy. This had never happened before, but it turned out the very restriction had never actually been enforced on the old virtual boxes. The kernel-level access was simply never granted to the virtualized guest! Harmless, because the application rules had worked as intended, but critical for our sense of security, and a real gain moving to dedicated hardware. This is something you just don't get on a VPS — confirming that a security boundary holds isn't a matter of reading an error message. The commands were accepted, but the infrastructure wouldn't run them.
The migration itself
Moving live compute, streaming databases, and spinning up customer apps into blue deploys on a fixed window — that was dozens of reversible steps, not one big one. That's a common misconception: just because you're moving to one big box doesn't mean the move has to happen all at once.
VPS or dedicated?
Stay on a VPS if your workload's I/O-light, doesn't need consistent high CPU, and the hardware convenience is a good fit. If you're not comfortable squeezing extra performance out of a Linux machine, put it off. The irony is that by the time you need that performance — and start seeing limitations at peak traffic times — it's likely other tenants squeezing your box. If compute cost is climbing faster than usage, or your security model can't be confirmed at the application level, it's time to move to a predictable, dedicated box.
One month since the migration, Canner has had >99.95% uptime, and we've seen builds run dramatically faster than we even expected. See the numbers on the changelog.