We're running a product built with Next.js, Vercel, and Supabase. It has more than 350,000 monthly visitors, about 12,000 registered users, and web, Android, and Windows clients. Most traffic is handled through caching, static pages, and incremental regeneration, so our current infrastructure costs only around $60–$70 per month.
We're now building a second related product and are wondering whether to keep using managed services or start preparing for a migration. A VPS with something like Coolify or Dokploy seems cheaper on paper, but I'm currently the only developer, and the main reason we chose managed hosting was to avoid server maintenance.
For a small team, how much work does running a VPS actually add? Is there a sensible middle ground using platforms such as Render, Railway, Fly, or managed Postgres? Does mostly regional traffic change the decision? And with two products, would you share infrastructure or isolate them?
There isn't a current performance or reliability problem. The concern is future growth: should we prepare for migration before the system becomes more complicated, or simply stay with Vercel and Supabase until costs, limits, or operational requirements create a real reason to move?
3 Answers
At your current cost and team size, I would stay on managed infrastructure. A VPS doesn’t just replace a hosting bill; it adds patching, backups, monitoring, security hardening, restore testing, incident response, and potentially high-availability work. Even a small amount of maintenance time can cost more than your entire monthly bill.
The decision point is operational rather than purely financial. Move when you need capabilities managed services can’t provide, when their pricing becomes materially worse for your workload, or when you have enough people to support the systems reliably. Until then, keep a cost model and document how the application is deployed so a future migration is possible without actually doing it prematurely.
Your low bill is probably explained by the workload rather than anything unusual: most public traffic is cached, much of the site is static or ISR, and only a small portion reaches the database or application functions. That is exactly the kind of workload managed platforms handle efficiently.
Regional traffic affects latency, data residency, and where you might place services, but it does not by itself make self-hosting worthwhile. Before considering a move, make sure you understand your actual bandwidth, function execution, database, storage, and egress usage. Also budget for paid tiers, backups, observability, and provider limits as usage grows. A gradual middle ground could be adding a CDN or edge layer, keeping the database managed, and moving only a specific workload if it becomes expensive.
I’d also avoid building around provider-specific features that would be difficult to reproduce elsewhere. Keep deployment and data export procedures documented, but don’t migrate solely because a future bill might be higher.
For two products, I’d separate them logically even if they share some underlying infrastructure. Use separate projects or environments, databases where appropriate, credentials, deployment pipelines, and access controls. That prevents a bad deployment or configuration change in one product from taking down the other.
You can still share common platform components such as a CDN, monitoring, CI tooling, or a carefully sized host. If the products have very different traffic patterns or reliability requirements, separate them physically later. I wouldn’t start with a self-managed VPS just to prepare for growth; instead, test backups and restores, document deployment, and set alerts for usage and performance. Those preparations preserve your options without creating a second job today.
That seems like the important distinction: a cheap VPS is not the same thing as cheap, reliable infrastructure. The server may cost less, but the engineering time and risk are part of the price.