How I Cut Infrastructure Costs Over 80% Without Kubernetes

Most teams overspend on cloud because they copy architecture diagrams, not production constraints. As CTO at Summit Lending, and through Moduletrace LTD work that keeps Circlenav, Datasquirel, Coderank, and Mediajury online, I ship on boring Linux servers with a sharp reverse proxy before buying a platform.

The goal is cost control with a reliability floor. A lean VPS stack (Hetzner or similar, NGINX, systemd, and owned CI runners) often lands past 80% lower infra spend than the default managed-cloud path when you do not need Kubernetes-grade orchestration. That figure is a recurring pattern from experience and bill reviews, not a single audited case study. Mileage depends on traffic, compliance, and managed glue on the invoice.

This playbook reduces infrastructure costs with VPS hosting without Kubernetes: start from traffic, put NGINX in front with product-matched caching, automate deploys with TurboCI (or GitHub/Gitea runners), measure homepage promises, then decide if you still need a cluster.

Why cloud bills balloon before products need Kubernetes

Kubernetes shines at multi-tenant scheduling, fleet rollouts, and teams with platform engineers. It is expensive as a default for a few services, moderate traffic, and one region.

Usual spend drivers:

1. Managed control planes and add-ons (ingress, certs, metrics, logging, secrets).
2. Idle capacity and over-provisioned node pools for burst that never arrives.
3. Egress and cross-AZ chatter that looks small in slides and large on invoices.
4. CI minutes billed per minute instead of owned runners on a cheap VPS.
5. Observability stacks priced like SaaS when SLOs are simple.

If you need production reliability for less money, ask what fails when the box reboots (and how fast you recover) before picking a CNCF chart.

Cost stack comparison: managed cloud default vs VPS + NGINX + owned CI

Illustrative shape for a small footprint (web apps, API, database, staging and prod). Order-of-magnitude patterns, not a quote.

| Layer | Managed cloud default | Lean VPS path | | --- | --- | --- | | Compute | Multiple small instances or a starter cluster | 1 to 3 Hetzner (or similar) VPS boxes sized to peak | | Edge / TLS | Managed load balancer + cert service | NGINX + Let's Encrypt (or ACME) on the box | | Caching | CDN or app-tier cache add-on | NGINX proxy_cache / static rules tuned to routes | | Deploy | Hosted pipelines + registry fees | TurboCI, Coolify, Dokploy, or self-hosted GitHub/Gitea runners | | Process model | Pods and deployments | systemd units (or Compose under a PaaS-on-VPS) | | Ops tax | Platform time on YAML and IAM | Linux, backups, firewall, disciplined deploys |

The lean path wins for a handful of named services. The managed path wins when compliance, multi-region failover, or multi-team tenancy is a real requirement.

Step 1: Start from traffic, not from a cluster diagram

Before you resize anything, capture peak RPS and concurrency for the last 30 to 90 days, which routes are static versus personalized versus write-heavy, what "down" means for revenue, and the bill split (compute, network, CI, observability).

At Summit Lending and on Moduletrace Org products, homepage and auth are separate SLOs. Marketing can cache hard; authenticated APIs cannot. That split decides how much NGINX can do without app changes.

Checklist: traffic reality

• [ ] Peak RPS and p95 latency per critical route
• [ ] Cacheability map (public / user-specific / write)
• [ ] Single-region vs true multi-region requirement
• [ ] RPO/RTO for databases and object storage
• [ ] Who pages when the box dies at 2 a.m. (Africa/Lagos or your on-call window)

Step 2: Put NGINX in front and make caching earn its keep

NGINX handles TLS, upstream health, rate limits, and safe caching. For Datasquirel-style data products and Mediajury-style media surfaces, public assets and anonymous HTML often absorb many hits before app workers.

Practical defaults:

• Terminate TLS at NGINX; keep apps on a private network or localhost.
• Use proxy_cache with short TTLs for anonymous pages; bypass Set-Cookie and auth paths.
• Add proxy_cache_lock so stampedes do not multiply origin load.
• Prefer explicit Cache-Control where personalization starts.
• Log cache status (HIT / MISS / BYPASS) to prove the savings.

Caching is not a substitute for a slow app. It cuts CPU and DB load on read-heavy traffic. Measure origin RPS before and after; that delta makes VPS right-sizing honest.

Step 3: Automate deploys with owned CI/CD

Hand-SSH does not scale past one engineer. Full hosted CI for every monorepo build burns money. Own the runners.

Options in Moduletrace LTD delivery:

• TurboCI for a focused self-hosted pipeline without renting minutes forever.
• GitHub Actions or Gitea Actions self-hosted runners on a small VPS.
• Coolify or Dokploy for Heroku-like UX on Hetzner, still without Kubernetes.

One orchestration style:

1. Build the artifact in CI (image or tarball).
2. Push to your registry or object store.
3. Deploy via SSH plus systemd restart, or Coolify/Dokploy hooks.
4. Health-check the NGINX upstream before flipping traffic.
5. Keep a one-command rollback (previous unit or image tag).

Sample deploy cadence (quiet production week)

| Day | Focus | | --- | --- | | Mon | Staging from main; smoke homepage and auth | | Tue | Production window; watch NGINX errors and app logs | | Wed | Cache and query review from Tuesday traffic | | Thu | Staging only; load-test a hot route if needed | | Fri | Freeze production except hotfixes; verify backups | | Sat-Sun | On-call only; no feature deploys |

Cadence beats heroics. Reliability comes from repetition, not unused cluster features.

Step 4: Measure the homepage promises you sell

Instrument "loads fast" and "always available": synthetic checks from two regions on homepage and login, disk/memory/systemd health on every VPS, and monthly restore drills. Add RUM only if you read it weekly.

On Coderank and Circlenav, dashboards matter less than NGINX health, an active app unit, and a minutes-long rollback. That is production reliability without a control plane tax.

Hardening mini-checklist

Do this before celebrating the bill drop:

• [ ] SSH keys only; disable password auth; firewall or VPN restrict
• [ ] Unattended security updates you understand
• [ ] Fail2ban (or equivalent) on SSH and sensitive endpoints
• [ ] TLS 1.2+ only; HSTS once HTTPS is everywhere
• [ ] Separate deploy user; least privilege for CI runners
• [ ] Encrypted backups off-box; tested restore
• [ ] Secrets outside git (vault or encrypted files)
• [ ] Log rotation and disk alerts before 100% full
• [ ] Runbook: restart, rollback, DNS failover

Skip this list and "cheap VPS" becomes an expensive incident.

When to still buy Kubernetes

Buy the cluster when teams need strong tenant isolation, multi-region active-active is a product feature, burst makes autoscaling pay for itself, contracts require a certified managed control plane, or idle VPS ops cost more in headcount than in cloud.

Until then, Kubernetes is often premature. Reducing infrastructure costs with VPS hosting still ships Circlenav, Datasquirel, Coderank, and Mediajury-class systems when you respect Linux, NGINX, and deploy discipline.

Common failure modes when people try this wrong

1. One giant VPS for everything with no staging twin. Savings vanish when a bad migrate kills prod.
2. Caching personalized pages and leaking user data. Bypass auth routes ruthlessly.
3. CI runners on the prod box without isolation. Builds starve the app.
4. No rollback artifact. "git pull on the server" will hurt.
5. Ignoring databases. Moving the web tier while leaving an oversized or unbacked data plane fixes neither bill nor risk.
6. Copying K8s habits onto Compose without health checks. Complexity stays; scheduler does not.
7. Cost cuts without SLOs. Finance is happy until support is not.

FAQ

Is this only for startups?
No. It fits teams with a finite service surface, a clear region strategy, and an ops owner who can run Linux. Mid-market product and lending stacks (Summit Lending included) often waste more on unused platform features than on missing cluster features.

What about compliance?
Compliance cares about access control, encryption, audit logs, backups, and evidence. Those are process problems on VPS or Kubernetes. If auditors require a specific managed platform, buy that. If they require demonstrable controls, a hardened Hetzner (or similar) stack with NGINX, systemd, and owned CI can meet many scopes. Map controls first; the invoice logo is not the control.

Will NGINX caching replace a CDN?
Sometimes for a single-region audience. For global static, keep a CDN, and still use NGINX origin caching.

Coolify vs Dokploy vs raw systemd?
Coolify and Dokploy speed up hosting UX on your VPS. Raw systemd is simpler for a small fleet. Choose by app count and UI need.

Closing

Cutting infrastructure costs without Kubernetes is not anti-cloud dogma. It is sequencing: prove traffic, put NGINX to work, own CI with TurboCI or self-hosted runners, measure homepage promises, and harden the box. Often the bill drops hard (past 80% is a pattern when teams were over-platformed). Sometimes you still graduate to a cluster; that decision is cleaner when you know what you paid for.

If you want a second set of eyes on an infra bill or VPS cutover plan, Moduletrace LTD offers consulting and audits. Bring the invoice lines and traffic notes; we will stay practical.