Paul
Most solo founders start their first platform on a managed hosting service like Vercel, Render, Heroku, Railway, or one of the other platforms that have made deployment dramatically easier over the last few years. That's the right call for a first platform because the time you save not configuring servers is time you can spend figuring out whether the platform itself is going to work, and the cost of managed hosting at small scale is genuinely reasonable when you're only running one thing. The question isn't whether to start there. The question is when to leave.
I've been on both sides of this transition more than once across my portfolio, and the timing matters more than most founders realize because moving too early wastes time you could have spent on the product, while moving too late wastes money you could have spent on basically anything else. I want to walk through the signals I actually look for when deciding to migrate a platform from managed hosting to self-hosted infrastructure, because the conventional advice on this question tends to be either "always use managed services" or "managed services are a scam," both of which miss the actual nuance.
What managed hosting is really good at
Before getting into when to leave, it's worth being honest about what managed hosting does well, because the answer is "a lot more than the self-hosting evangelists admit." Managed platforms like Vercel and Render handle the deployment pipeline, the SSL certificates, the basic monitoring, the rollbacks, the preview environments, and a dozen other things that would each take you a few hours to set up on a self-hosted server and then a few minutes per week to maintain forever after. For a first platform where you're optimizing for speed of iteration rather than cost, paying $20 to $50 a month to skip all of that is a genuinely good trade.
The other thing managed hosting does well is absorb the operational risk during the period when you can least afford to deal with it, which is the early days of a platform where you're still figuring out whether anyone wants what you built. If your Vercel deployment goes sideways at 2am, it's Vercel's problem and they have a team of engineers handling it. If your self-hosted server goes sideways at 2am, it's your problem and you're the team handling it. That difference is worth real money when you're trying to focus on the product rather than the plumbing.
And managed hosting integrates well with the modern web framework ecosystem in ways that take work to replicate yourself, where things like Next.js ISR, edge functions, image optimization, and CDN delivery all just work without configuration. Replicating those features on self-hosted infrastructure is possible but requires real engineering effort, and for platforms that don't have the traffic to justify that engineering effort, paying the managed hosting premium is the rational choice.
The signals that it's time to leave
The first signal that you should consider moving is when the monthly bill stops feeling like a rounding error and starts feeling like a meaningful line item in your costs. For most managed platforms there's a soft threshold where you're paying $20 to $100 a month and barely noticing, and a harder threshold that's over $500 a month where the bill starts to actively bother you. When you're in the second range and the platform is generating less revenue than the hosting costs, that's a signal that the math has stopped working and self-hosting deserves a serious look.
The second signal is when you start running into platform limits that affect what you can build. Managed hosting platforms enforce caps on things like build minutes, function execution time, bandwidth, concurrent requests, and database connections, and most platforms hit at least one of those caps eventually if they grow. When you find yourself architecting around a limit rather than around what your users need, that's the platform telling you it's not the right fit anymore. The limits exist for good reasons on the managed provider's side, but they're real constraints on your product and you don't have to accept them forever.
The third signal is when you're running multiple platforms simultaneously and the per-platform cost of managed hosting starts compounding. One platform on Vercel for $40 a month is fine. Five platforms on Vercel for $200 a month is fine if four of them are generating revenue, but uncomfortable if only one is. Ten platforms on managed hosting at typical pricing tiers will easily exceed $500 a month, and that's the same money that would buy you significantly more capacity on self-hosted infrastructure with room to grow. The economics of running a portfolio of platforms are fundamentally different from running one, and managed services that make sense for the first situation rarely make sense for the second.
The fourth signal is when you need a level of control that managed platforms don't expose. Maybe you want to run a background worker that needs to live longer than the managed function timeout. Maybe you want to use a database extension that isn't supported by the managed Postgres provider. Maybe you want to deploy a binary that doesn't fit the runtime model your hosting platform expects. When the answer to "can the managed platform do this" starts being "no" more often than "yes," that's the platform's way of telling you it's grown out of the model that worked when you started.
The fifth signal is when you've developed enough operational comfort that self-hosting doesn't scare you the way it used to. This is the underrated signal because it's about you rather than the platform, but it matters because the decision to self-host requires you to actually do the work, and the work is genuinely easier once you've developed the skills than it was on day one. If you started a year ago not knowing how to SSH into a server and you now run multiple platforms confidently, the friction of moving has dropped significantly even if the platforms themselves haven't changed.
When NOT to leave
The honest counterpart to all of this is that there are scenarios where staying on managed hosting is the right call indefinitely, and I want to lay those out clearly so people don't move just because they read a blog post telling them to. The first case is if your platform is genuinely small and likely to stay small, where the managed hosting bill is going to remain a rounding error and the time you'd spend learning self-hosting is better spent on the product itself. Not every platform needs to scale into the territory where infrastructure costs matter.
The second case is if you have zero interest in operations and genuinely don't enjoy the work of running servers, in which case paying the managed hosting premium is just buying back time you'd otherwise spend on work you hate. That's a completely legitimate trade and I'm not going to pretend otherwise. The third case is if your platform has unusual technical requirements that the managed providers actually solve well, like geographically distributed edge functions or extremely high availability with automatic regional failover, which are genuinely hard to replicate on a self-hosted setup and might be worth paying for.
The fourth case is if you're at a stage in your founder journey where you need to focus exclusively on product and distribution and you simply don't have the bandwidth to also be learning infrastructure. That's a real constraint and the right answer in that situation is to pay for managed hosting until you have the breathing room to consider migrating, rather than trying to do everything at once and doing all of it poorly.
What the migration actually looks like
Once you've decided to move, the migration itself is less scary than what people typically imagine, but it does require setting aside dedicated time and being honest about the fact that it's a project rather than an afternoon. The general shape of the work is that you spin up a server (or servers) on your chosen provider, install the runtime your application needs, deploy your code (copy over via rsync for example), set up the database and any supporting services, configure SSL through something like Caddy or Nginx with Let's Encrypt, set up basic monitoring, and then cut DNS over from the managed service to your new infrastructure.
Claude Code can make this whole migration meaningfully easier than it would have been two years ago, because every step in that task list is something you can walk through with the model as your guide rather than having to dig through Stack Overflow alone. You can describe your existing managed setup, paste in your package.json and your environment variables, and have Claude generate the systemd service files, the Nginx config, the Let's Encrypt setup, and the deploy scripts you need to actually run the platform. It's not magic and you still need to understand enough about what's happening to catch mistakes when the model gets something wrong, but the experience of doing the migration with Claude Code in a terminal next to you is fundamentally different from doing it the old way where you had to figure out each piece in isolation. For solo founders who've been putting off learning self-hosting because the learning curve felt too steep, the curve is genuinely shorter now than it used to be, and that changes the math on when migration becomes the right call.
The first time you do this it takes a weekend because you're learning the patterns. The second time it takes maybe a day because you've written down what you learned. By the tenth time, which sounds like a lot but happens fast when you're running a portfolio, the migration is a few hours of focused work that you can fit between other projects. The learning curve is real but it's also short and finite, where the same skills apply to every future platform you'll ever ship.
The piece that catches people off guard isn't the technical migration but the operational ramp-up afterward, where you're now responsible for things the managed platform was quietly handling. You need to think about backups, you need to think about monitoring, you need to think about security updates, and you need to think about what happens when something breaks. None of these are hard individually but they all require attention that the managed platform was absorbing for you, and underestimating that ongoing cost is the most common mistake I see in founders who migrate too aggressively.
The way to handle the operational ramp-up is to migrate one platform first, run it in parallel with the managed version for a week or two to make sure everything works, develop the muscle memory for handling the platform's needs, and then migrate the rest of the portfolio one at a time as you gain confidence. Trying to move everything at once is a recipe for being underwater on operational work for weeks while you sort out the issues, and that's exactly the kind of stress that makes founders quit migrations halfway through and conclude that self-hosting is a mistake.
What you should set up before the migration
The things worth getting right before you cut DNS over to your self-hosted infrastructure are the operational basics that the managed platform was handling for you, and skimping on any of these is the fastest way to regret the move. Automated backups need to be running and tested, because a database without working backups is a time bomb and the managed providers were quietly handling this for you. Basic monitoring needs to be in place so you find out about problems before your users do, which can be as simple as an uptime check from a third-party service and email alerts when the server is unreachable.
Server security needs to be locked down before the platform handles real traffic, because the managed platforms were taking care of the surface area you didn't even think about. That means SSH keys rather than passwords, firewall rules limiting what can talk to your server, automatic security updates configured, and your databases on a private network rather than exposed to the internet. None of this takes long but all of it is necessary, and skipping it because you're in a hurry to migrate is how solo founders end up with crypto miners running on their boxes a month later.
You also want a deployment process that's at least as smooth as what you had on the managed platform, because the friction of every future deploy adds up over the life of the project. This doesn't have to be elaborate, but it should be a single command that pushes your code from your local machine to the server, runs any database migrations, restarts the application, and reports back whether it worked. The managed platforms set the bar here and self-hosted setups that don't match it will quietly make you slower without you noticing.
One thing I always do before pointing real traffic at a new server is a 48 hour burn-in period where I run the platform on the new infrastructure but keep the managed version live as the primary, so I can watch how the self-hosted setup behaves under realistic conditions without users feeling any of the rough edges. The idea is that the first 48 hours after a fresh server setup is when the dumb mistakes surface, where a misconfigured cron job fills the disk, a memory leak in some dependency reveals itself, a backup script silently fails on its first scheduled run, or a security update reboots the server in the middle of the night and nothing comes back up cleanly. Catching any of those issues while the managed version is still serving your real users means the rough edges become a learning opportunity rather than an outage, and skipping the burn-in is the kind of false economy that turns a clean migration into a stressful one.
The way I run the burn-in is to send a small fraction of synthetic traffic to the new infrastructure (or just hit it manually a few times an hour with the patterns my real users would use), check the logs every few hours for anything unexpected, and verify that backups, monitoring, and scheduled tasks all run at least once during the window. If anything looks off, I fix it on the new server while the managed version keeps serving production. If everything looks clean after 48 hours, I cut DNS over with much more confidence than I would have on day one, because the server has now actually proven itself rather than just theoretically being ready.
The honest summary
Managed hosting is the right call when you're starting out, when you only have one or two platforms, when your traffic is modest, when you genuinely don't enjoy operations work, or when you have unusual technical requirements that the managed providers solve well. Self-hosting becomes the right call when you're running multiple platforms, when the monthly bill is starting to bother you, when platform limits are constraining what you can build, or when you've developed enough operational comfort that the work doesn't feel scary anymore.
The transition point is rarely obvious in advance because it depends on factors that are specific to your situation, but there's usually a moment where you're paying a lot of money for convenience you don't need anymore and you can feel that something has shifted. When that moment arrives, take it seriously, because the cost of staying on managed hosting past that point compounds quickly across multiple platforms and the cost of learning to self-host is mostly a one-time hit that pays off for years afterward.
The bigger picture is that solo founders building portfolios of platforms over time are going to develop infrastructure skills whether they want to or not, and the question is just whether you develop those skills proactively or whether you wait until a managed platform's pricing or limits force you to. Doing it proactively is almost always cheaper in the long run, both in dollars and in stress, because you're learning under conditions you control rather than under the pressure of needing to migrate quickly because the economics broke. And the skills themselves are genuinely valuable, where every platform you build for the rest of your life will benefit from understanding how the underlying infrastructure actually works.
