One VPS is often the right starting architecture for a SaaS MVP: the web app, database and background workers can live on one VM when backups, monitoring and boundaries are designed deliberately. Buying many servers on day one is not scalability - preserving clean paths to separate future bottlenecks is more useful.
Scenario: the first 100 paying users
You have an API/web app, PostgreSQL or MySQL, a few queue workers and an external transactional-email provider. At this stage, one VPS is often economical, easier to debug and operationally simple.
Version-one architecture
| Component | Location | Reason |
|---|---|---|
| Reverse proxy | same VPS | TLS/public edge |
| Application | same VPS | simple deployment |
| Database | same VPS | low complexity |
| Workers | same VPS | initial workload |
| Backup | separate failure domain | recovery |
the background-workers guide helps structure queues and cron safely. Use the MySQL/PostgreSQL VPS guide for database memory planning.
Four growth triggers
- DB memory or I/O grows: move the database to its own VPS.
- Workers consume CPU: separate async capacity.
- Uploads grow: introduce a deliberate file/object-storage strategy.
- Web concurrency grows: add another app node only when vertical scaling is no longer enough.
Do not postpone these because it is “only an MVP”
- backup and restore testing;
- TLS and secret management;
- monitoring and alerts;
- deployment rollback;
- database migration discipline;
- correct transactional email configuration - see our SMTP explainer.
Cost discipline: pay for complexity only when the benefit is measurable
A separate database, Redis, load balancer and extra workers each introduce operational tax. If p95 latency, backup windows and recovery objectives are healthy on one VPS, premature distribution often creates more failure modes than value.
If Linux maintenance distracts founders or developers from product work, Managed VPS may be economical. Teams with established operations skills may prefer unmanaged flexibility.
Good MVP infrastructure is small, understandable and designed with clear exits for future growth.
