Cloud costs on a startup budget: free tiers, VPS and when to move up
You do not need a multi-region Kubernetes cluster to launch. A staged infrastructure plan keeps costs proportional to revenue — without painting you into a corner.
By Aadhyay Editorial2 min read
Early infrastructure decisions are often made by imitation: big companies run Kubernetes on hyperscalers, so new products start there too. The result is a monthly bill — and an operational burden — sized for a scale that may be years away.
A better approach ties infrastructure stages to clear triggers: number of customers, revenue, reliability requirements. Each stage is cheap to run and easy to leave.
Stage 0: build and pilot for (almost) nothing
Before the first paying customer, free tiers can run surprisingly capable stacks. Some providers offer always-free ARM virtual machines; edge platforms offer free DNS, CDN and TLS; object storage and transactional email have free allowances.
Stage A: first customers on a small, paid server
When customers pay, move to paid servers with predictable pricing, ideally in a region close to your users. A single application server plus a separate database server, both running Docker Compose behind a reverse proxy with automatic TLS, handles a lot of traffic for a modest monthly cost.
- Containerise everything so the move is a restore plus a DNS change.
- Keep the database on a private network.
- Add continuous backups (write-ahead log shipping) for a recovery point measured in minutes.
- Monitor uptime, disk and certificate expiry from day one.
Stage B and beyond: scale what is actually busy
As usage grows, scale the components under pressure rather than everything. Real-time features and background jobs often need their own nodes first. Managed databases become attractive when the time saved on operations exceeds the price difference.
| Trigger | Typical change |
|---|---|
| Database CPU regularly high | Dedicated-CPU database server or managed database |
| Deploys cause noticeable blips | Second application node behind the proxy |
| Recovery objectives tighten | Streaming replica in a second region |
| More than a handful of services and teams | Consider a container orchestrator |
A rule for spending
A simple guard-rail helps: recurring infrastructure spend should stay a small, deliberate fraction of revenue, reviewed monthly. Track cost per customer as a metric alongside revenue per customer.
Design choices that keep the bill low
- Push routine notifications through free channels (app push, email) and reserve paid messaging for important events.
- Compress media on the client before upload and expire temporary files.
- Use peer-to-peer where protocols allow, relaying only when needed.
- Cache public pages at the edge.
None of this prevents you from adopting larger platforms later. Containers, infrastructure as code and vendor adapters make the move a planned migration rather than a rewrite. If you want a review of your current setup, our cloud services team can help.
Aadhyay Editorial
Engineering and editorial team