We currently run 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, while infrastructure costs are roughly $60–$70 per month. The low cost is largely due to CDN caching, static and ISR pages, limited dynamic rendering, optimized database access, and keeping background jobs outside the hosting platform. Traffic is mostly regional, and the product is still relatively new and lightly monetized.
We are building a second related product, so I'm wondering whether we should prepare for a migration before the setup becomes more complicated. A VPS with something like Coolify or Dokploy could be cheaper and provide more control, but I'm currently the only developer and don't want to take on a large maintenance burden.
For a small team that has made this transition, how much work is involved in maintaining a VPS properly? Would a middle ground such as Render, Railway, Fly, managed Postgres, or additional Cloudflare services make more sense? Does regional traffic change the calculation? And if we eventually move both products, should they share infrastructure or be isolated?
There are no major performance or reliability problems today, so the main question is whether to plan the migration now or continue with managed services until there is an actual bottleneck or the economics stop working.
5 Answers
For the two products, I’d separate them logically from the start with different projects, environments, credentials, deployment pipelines, and resource limits. They can share a provider or some platform tooling, but one product should not be able to take down the other through a bad deployment, runaway job, or database issue.
You don’t necessarily need completely separate servers on day one. Shared infrastructure is reasonable while both products are small, then split them when their reliability, scaling, or security requirements diverge.
At this price and with one developer, I would stay with Vercel and Supabase. A VPS is not just a monthly hosting bill—you also take responsibility for patching, backups, monitoring, security, restores, deployments, and handling incidents. Even a small amount of maintenance time can cost more than the infrastructure savings.
The useful trigger is usually operational rather than traffic-based: move when you need capabilities the managed services cannot provide, have a clear cost problem, need more control or compliance, or have enough people to support the system. Until then, keep a migration plan and monitor usage, but don’t migrate preemptively.
It’s also worth looking at product economics before optimizing a $60–$70 bill. If hundreds of thousands of visitors are producing only around 12,000 registrations, improving activation or conversion could have far more impact than reducing hosting costs. Keep the current setup, pay for the tiers that provide the reliability you need, and revisit infrastructure when there is a concrete technical or financial reason.
Regional traffic mostly affects latency, data residency, and where you place caches or compute. It doesn’t by itself make self-hosting worthwhile. Your current numbers suggest that most visitors are being served efficiently through caching, so traffic volume alone is not a strong reason to change platforms.
I’d build a simple 12-month forecast for usage and provider costs, set alerts before hitting paid-tier limits, and document how you would export data and redeploy elsewhere. That gives you migration readiness without paying the operational cost of migrating early.
You can use a middle ground later, such as putting more caching and edge logic in front of the existing stack, moving selected workloads to a managed container platform, or keeping the database managed while running application containers elsewhere. That gives you more control without immediately becoming responsible for the entire platform.
If you do evaluate self-hosting, price the complete package: multiple instances if downtime matters, backups and restore testing, observability, security updates, failover, bandwidth, and your own maintenance time. A single inexpensive VPS is easy to deploy, but it is also a single point of failure.
That matches my concern. I was mostly worried that waiting would make a future migration impossible, but documenting exports, deployment steps, and the parts of the platform we rely on seems like a better investment for now.