How I hosted the Saarthix platform solo at minimal cost

A DevOps case study: edge, load balancer, API gateway, Kubernetes, CI/CD, observability and security, built and run by one engineer on a startup budget.

The problem: a real platform, no infra team

Saarthix started the way most products do: a small team, a lot of features to ship and no one whose job was infrastructure. I was leading product engineering, writing Spring Boot services and React screens. When it was time to go to production, there was no platform team to hand it to, and no budget for a large managed setup.

So I took it on. The brief I gave myself was simple to say and hard to do:

• Reliable enough for real users. No single box that takes everything down when it dies, and no deploy that means downtime.
• Cheap enough for a startup. Every component had to justify its monthly bill.
• Simple enough for one person to run. If something broke at 2 a.m., I was the on-call rotation, so the system had to explain itself.

The architecture, layer by layer

A request to Saarthix passes through five layers. Each one has a single job, and each one can be scaled, swapped or debugged on its own.

1. Edge and CDN: Cloudflare

Everything starts at Cloudflare. It handles DNS, terminates TLS close to the user, caches static assets and images at the edge, and runs the WAF and bot protection. Most frontend traffic never reaches my servers at all, which is the single biggest saving in the whole design: origin bandwidth and compute you don't use cost nothing.

I set cache rules per path, so the React bundle and images get long cache lifetimes with hashed filenames, while API routes bypass the cache entirely. Images go through imgproxy behind the cache, so resized variants are generated once and then served from the edge.

2. Load balancer: Nginx at L7

Behind the edge sits an Nginx layer-7 load balancer. It spreads traffic across healthy backends, runs active health checks, and retries a request on another upstream when one fails. Keeping this layer self-hosted instead of paying for a managed load balancer per environment was a deliberate cost decision.

3. API gateway: Kong as the single front door

All API traffic goes through Kong. It is the one place where cross-cutting rules live: authentication, rate limiting, request size limits, CORS and routing to the right service. That keeps the Spring Boot services focused on business logic, and it means a new service gets the same security posture by adding a route, not by copying code. Paid managed gateways bill per request; a self-hosted Kong is a fixed, small cost.

4. Compute: Kubernetes

The services run on Kubernetes, packaged as Helm charts. Each deployment has resource requests and limits, readiness and liveness probes, and a Horizontal Pod Autoscaler. If a pod crashes, Kubernetes restarts it; if traffic climbs, the HPA adds replicas; when traffic drops off-peak, it scales back down to the floor.

Kubernetes is often called overkill for a small team. For one person, I found the opposite: it replaced a pile of hand-written scripts for restarts, rollouts and scaling with a declarative system that does the boring work for me.

5. Data: PostgreSQL, MongoDB and Redis

PostgreSQL holds the core relational data, with PgBouncer in front to pool connections so a burst of pods doesn't exhaust the database. MongoDB stores document-shaped data, and Redis handles caching and short-lived state. Databases get automated backups and I test restores, because a backup you have never restored is a guess.

CI/CD: from git push to production

Every push to the main branch runs the same pipeline, and nobody (including me) deploys by hand:

1. Lint and test the code.
2. Scan dependencies, container images and infrastructure code with Trivy. CRITICAL or HIGH findings fail the build.
3. Build multi-stage Docker images, so production images contain only the runtime and the app.
4. Push the image with an immutable tag tied to the commit.
5. Deploy with a Kubernetes rolling update: new pods must pass readiness before old ones are removed, which is how deploys stay at zero downtime.
6. Verify with smoke checks against the new version, and roll back automatically if they fail.

Infrastructure is code too. Terraform describes the cloud resources, so environments are reproducible and every change is reviewed in a pull request, not clicked together in a console.

Observability: knowing before users do

Running a platform alone only works if the platform tells you what is wrong. I run an open-source observability stack: Prometheus for metrics, Grafana for dashboards, Loki for logs, and Alertmanager for alerts. Every service exposes metrics, every request carries an ID through the gateway into the logs, and the main dashboards follow the golden signals: traffic, latency, errors and saturation.

Alerts are tied to symptoms users feel, such as error rate or slow responses, rather than to every CPU spike. Fewer, better alerts are what make solo on-call survivable. Self-hosting this stack instead of paying for a SaaS observability tool is another fixed, predictable line on the bill.

Security: least privilege by default

• At the edge: Cloudflare WAF rules and rate limiting stop the noisy traffic before it costs anything.
• At the gateway: Kong enforces authentication and per-client rate limits for every API route.
• Secrets: stored in Vault, never in Git or baked into images.
• Access: least-privilege IAM for people and for workloads, so a compromised component can only reach what it needs.
• Supply chain: every image is scanned in CI, and builds fail on serious vulnerabilities or misconfigurations.

Cost optimisation: production-grade on a startup budget

Cost was a design requirement from day one, not a clean-up job afterwards. The main levers:

1. Let the edge do the work. CDN caching at Cloudflare removes most origin traffic and egress.
2. Self-host the commodity layers. Nginx and Kong instead of per-request managed load balancers and gateways.
3. Right-size everything. Requests and limits based on real usage, ARM and spot or preemptible capacity where the workload tolerates it.
4. Bin-pack and scale to the floor. Containers share nodes efficiently, and autoscaling shrinks the platform at night.
5. Open-source observability. Prometheus, Grafana and Loki instead of a per-host or per-GB SaaS bill.
6. Treat cost like an SLO. Tags, budgets and alerts mean a cost spike gets noticed the same day, like any other incident.

Results

Lessons learned

Boring and declarative beats clever

The parts of the system I trust most are the ones I describe, not the ones I script: Terraform for infrastructure, Helm for workloads, a pipeline for delivery. When the state of the world lives in Git, recovering from a mistake is a revert.

Put rules at the layer that owns them

Caching belongs at the edge, routing and auth at the gateway, retries at the load balancer, scaling in Kubernetes. When every layer has one job, debugging becomes a question of which layer is unhappy, and the dashboards answer it.

Cost is a feature

Designing for cost from the start was much easier than cutting it later. Most of the savings came from architecture choices, not from discounts.

Observability is what makes solo possible

One person can run a production platform only if the platform reports its own problems clearly. Investing in metrics, logs and good alerts early paid for itself the first time something went wrong.

← Back to Hariom Singh's DevOps portfolio