There's a persistent myth in indie hacker circles that a "real" SaaS needs a multi-node architecture, managed Kubernetes, and a separate database cluster before it has its first paying customer. In practice, a single well-configured VPS comfortably serves thousands of users for most B2B SaaS products, and over-engineering the infrastructure before you've found product-market fit is one of the more common ways solo founders burn their limited time budget.
Why one server is usually enough
Most early-stage SaaS products are not compute-bound — they're bound by how fast you can ship features customers actually want. A modern 4-8 vCPU VPS with an NVMe-backed disk can serve a surprising amount of traffic: a typical CRUD-heavy multi-tenant web app with a Postgres or MySQL backend, some background jobs, and a moderate number of concurrent users runs comfortably on hardware costing $40-80/month, long before you'd need to think about horizontal scaling.
Sizing your first server
Start smaller than you think you need — a 2 vCPU / 4GB RAM instance is plenty for a pre-launch or early-access product — and treat vertical scaling (resizing the same instance to more CPU/RAM) as your first lever. Almost every major VPS provider supports a live or near-live resize with a short reboot, which is dramatically simpler than re-architecting for horizontal scale before you need it.
The stack: keep it boring
Pick technology you can operate at 2am when something breaks, not what's trending this month. A reasonable default for a solo founder: Nginx as the reverse proxy and static file server, a single application runtime (Node.js, PHP, Python/Django, or Ruby — whichever you already know well), and Postgres or MySQL as the primary datastore. Boring, well-documented technology means every problem you hit has already been solved and written up by someone else.
Process management
Whatever runtime you choose, run it under a supervisor that restarts it automatically on crash and on server reboot — PM2 for Node.js, Gunicorn with systemd for Python, or systemd unit files directly for anything else. The specific tool matters less than the property: your app should survive a crash or a reboot without you SSHing in at 3am to restart it by hand.
The database
Run the database on the same VPS as the application for as long as you reasonably can — the network round-trip you save by keeping them co-located is real, and a separate database server is operational complexity you don't need yet. Configure automated daily dumps to off-server storage (see our backup guide), and set conservative connection pool limits so a traffic spike in your app doesn't starve the database of connections.
File storage and uploads
User-uploaded files (avatars, documents, generated exports) are the one thing worth keeping off the application server from day one, because local disk fills up quietly and doesn't scale if you ever do need a second app server. Object storage (S3-compatible, offered by most VPS providers as an add-on) is cheap and removes an entire category of "the disk filled up" incidents. If you're serving a lot of images specifically, see our guide to self-hosting an image CDN.
Logging and error visibility
Before you have real users, set up basic uptime monitoring and centralized error logging (see our budget monitoring guide). The goal isn't a full observability stack — it's knowing about an outage before a customer emails you about it.
When to actually split things up
Split the database onto its own server when you're consistently seeing CPU or memory contention between the app and database processes, not before. Add a second application server (behind a load balancer) when you need redundancy for uptime reasons, or when a single instance's vertical scaling ceiling is genuinely limiting you. For most SaaS products, that point arrives much later than founders expect — often well past $10-20k MRR, sometimes never.
Frequently asked questions
How many users can a single VPS realistically support?
It depends far more on what each user does than on raw headcount — a CRUD-heavy SaaS with modest concurrent activity can serve many thousands of registered users on a mid-tier VPS, while a handful of users running constant heavy queries could strain the same box. Watch resource usage under real load rather than trusting any fixed number.
Should I use a managed database service instead of self-hosting on the same VPS?
Not necessarily at first — co-locating the database with the app is simpler and cheaper early on. Move to a managed or separate database once you have a specific reason (contention, need for read replicas, or wanting to offload operational burden), not by default.
What's the single biggest mistake founders make with early SaaS infrastructure?
Over-building for scale they don't have yet, at the cost of time that should go into the product itself. A single well-configured VPS with good backups and monitoring is more than sufficient infrastructure for the large majority of SaaS products in their first one to two years.