The monthly invoices from my old infrastructure stack told a familiar story. A $15 managed WordPress host here, a $12 Node.js app platform there, $9 for a container hosting service, $7 for a managed Redis instance, and separate charges for SSL certificate automation and backup storage. The total was $68 a month. I was running four small production services and paying that spread across six different dashboards, six support queues, and six billing pages with six different quirks.

I collapsed everything onto a single $50 month server VPS at Hetzner. That was fourteen months ago. The combined monthly bill is now $52 — $50 for the server, $2 for hourly backups through Hetzner’s snapshot service. I run WordPress with PHP-FPM, two Node.js apps, a Dockerized monitoring stack, and a small PostgreSQL instance. The server has seen one maintenance window in fourteen months, and it was scheduled. This piece documents exactly how that architecture works, where the limits are, and when the consolidation trade-off stops making sense.

What $50 Buys You in 2026

The $50/month VPS tier has meaningfully converged across major providers over the past two years. Here is what you can actually provision at that price point in March 2026:

The Contabo numbers look generous on paper — 30 GB RAM for $50 is real — but their network latency in European datacenters runs noticeably higher than Hetzner, and their CPU performance per core lags behind the competition. For latency-sensitive Node.js applications, that matters. The DigitalOcean and Vultr plans give you dedicated vCPUs, which means predictable performance without noisy-neighbor effects at the cost of substantially less RAM and transfer. Hetzner’s CX42 is the default recommendation for mixed workloads: 16 GB RAM, fast NVMe, and 20 TB transfer at current USD conversion rates make it the strongest general-purpose option at this price.

One distinction worth internalizing: dedicated versus shared vCPUs. Shared vCPUs on Hetzner’s platform rarely cause problems in practice for workloads under moderate sustained load — my CX42 has never shown CPU steal above 3% over the past year. But if you’re running a workload that holds CPU at 40% or more for extended periods, a four-core dedicated option from DigitalOcean or Vultr will behave more predictably.

The Architecture: Nginx as the Load Balancer You Already Own

The core architectural pattern for a single-server multi-service setup is straightforward: Nginx acts as a reverse proxy at the edge, terminating SSL, routing traffic by hostname, and passing requests upstream to individual services that bind only to localhost ports. WordPress runs under PHP-FPM listening on a Unix socket. Node.js processes bind to ports 3001, 3002, and so on. Docker containers expose their services on internal ports, and Nginx routes to them by name through Docker’s bridge network.

This is not exotic. It is the configuration that every experienced operator arrives at independently. The value is that Nginx handles everything visible from the internet — TLS, HTTP/2, gzip, static file caching — while the application processes behind it need no networking knowledge at all. They just answer requests on localhost.

Nginx Configuration Pattern

The server block structure for three domains — a WordPress site, a Node.js API, and a Dockerized app — looks roughly like this. Each service gets its own server block with a proxy_pass directive pointing at the appropriate upstream. WordPress is served through a fastcgi_pass to PHP-FPM’s Unix socket. Static WordPress assets are served directly by Nginx from the filesystem, which eliminates PHP processing overhead for images, CSS, and JavaScript — on a moderately trafficked site this alone reduces PHP-FPM worker usage by 60 to 70 percent.

Rate limiting deserves attention here. A naive multi-service setup without rate limits on the Nginx layer is vulnerable to a single misbehaving client saturating PHP-FPM workers and starving the Node.js services of connection threads. A simple limit_req_zone directive capped at around 20 requests per second per IP keeps any single client from degrading the entire server.

Resource Allocation: Where the 16 GB Actually Goes

Fourteen months of production data from my CX42 gives a clear picture of how an 8-vCPU, 16 GB server distributes its resources across a typical mixed workload:

Total reserved: approximately 6.4 GB, leaving roughly 9.6 GB of headroom. In practice, Linux uses available RAM for filesystem caching, so the server runs at around 11 GB utilized during normal operation — almost entirely cache. The 5 GB of genuinely free RAM serves as a buffer against traffic spikes. On a heavy traffic day — a content piece going modestly viral, around 8,000 sessions in twelve hours — peak RAM usage reached 13.2 GB. The server handled it without intervention.

Docker Compose Resource Limits

One operational mistake that surprises people is deploying Docker containers without memory limits. A containerized service with a memory leak or an unexpectedly large workload will simply take RAM from every other service on the host. Setting explicit limits in docker-compose.yml is non-negotiable for a shared server. A practical configuration specifies both mem_limit and memswap_limit, with the swap limit set equal to the memory limit to prevent disk swap from masking memory pressure. When a container hits its limit, it crashes and Docker restarts it — which is a far better failure mode than slowly degrading every other service on the box.

CPU limits in Docker Compose are worth using for containers that do batch work — image processing, scheduled report generation, large database queries — but are generally unnecessary for serving containers under normal traffic. The overhead of CPU quota enforcement adds latency at high concurrency and rarely benefits a lightly loaded multi-service server.

SSL for Multiple Domains Without the Complexity

Managing TLS certificates for four or five domains on a single server was genuinely tedious before Certbot’s webroot and DNS challenge plugins matured. Today it is about twenty minutes of setup that runs unattended for years. The critical configuration detail: run a single Certbot installation that manages all certificates centrally, rather than attempting to configure per-site certificate management. The renewal cronjob — certbot renew --quiet fired twice daily — handles everything. Nginx reloads automatically when certificates renew via a deploy hook.

One detail that catches operators off guard: HTTP/2 is not automatically enabled by adding an SSL certificate. The listen 443 ssl http2 directive needs to be explicit in each Nginx server block. On a multi-service server where some upstream connections are PHP-FPM Unix sockets and others are proxied HTTP to Docker containers, the HTTP/2 benefits are almost entirely at the client edge — the internal Nginx-to-upstream connections remain HTTP/1.1 regardless. For a typical content site this makes a measurable difference in page load perception even if raw throughput changes little.

Monitoring Without Eating Your Own Resources

This is where well-intentioned operators make a persistent mistake. Prometheus with a full Grafana dashboard stack consumes around 1.2 to 1.8 GB of RAM at steady state. On a 16 GB server running production workloads, that is a significant commitment for something whose primary function is telling you the server is doing fine. The monitoring stack should not be the second largest consumer of RAM on your server.

My current approach layers three tools with complementary scopes:

• Netdata as the primary system monitor. It uses roughly 90 MB of RAM, ships with useful defaults, and its real-time dashboard answers 90% of questions about what the server is doing right now. For a single-server operator, this is sufficient most of the time.
• Prometheus with node_exporter only — no application-level scraping, no long retention — running inside Docker with a 512 MB memory limit. This satisfies the requirement to have queryable historical metrics without deploying the full observability stack.
• Uptime Kuma as an external-facing health check. It runs as a Docker container, checks each service endpoint every 60 seconds, and sends alerts via Telegram. The total RAM footprint is under 100 MB.

Grafana is genuinely useful but represents a luxury on a constrained server. If you want visual dashboards, consider running Grafana on a separate free-tier VM or using Netdata’s cloud integration, which ships metrics off-server for visualization without local resource cost.

Backup Strategy: Fast, Cheap, and Not Self-Defeating

A backup strategy that transfers 40 GB of data nightly is consuming bandwidth that was supposed to serve your users. The practical approach separates database backups from filesystem backups and uses different tools and cadences for each.

Database backups — the data you actually cannot reproduce — run on a tight schedule. mysqldump for WordPress, pg_dump for PostgreSQL, piped through gzip and written to a local staging directory, then synced to an S3-compatible object store with rclone. The compressed dumps for a typical WordPress site and a small PostgreSQL database total around 200 to 400 MB. At Backblaze B2’s pricing of $0.006 per GB per month, storing 30 days of database backups costs under $0.10 a month. The bandwidth for the initial upload and daily incremental changes is negligible.

Filesystem backups use Restic or BorgBackup with deduplication. After the initial full backup, incremental daily snapshots typically add 5 to 50 MB depending on how much content changed. Monthly bandwidth cost for filesystem backup sync is usually under 2 GB. The critical configuration detail is excluding the directories that do not need backup: Docker image layers, PHP-FPM temporary files, Nginx cache directories, and application log archives. A naive full-filesystem backup without exclusions can easily be 10 to 20 times larger than necessary.

Hetzner’s snapshot feature — the $2/month line item on my bill — provides a full server image daily. This is the recovery option of last resort, not a substitute for application-level backup. If a bad deployment corrupts the database, the snapshot restores to a point before the deployment. If a wayward DELETE query removes production data, you need the pg_dump file from before the query ran.

The Hidden Time Costs

No honest treatment of single-server VPS operation omits this. The economics in favor of self-hosting are real, but they assume your time managing the server has a cost you are comfortable absorbing. Based on fourteen months of operation, the actual maintenance time breaks down as follows:

• OS and package updates: 30 to 45 minutes per month. Ubuntu’s unattended-upgrades handles security patches automatically; I manually review and apply major version upgrades.
• Incident response: In fourteen months, three incidents requiring active intervention. Total time: approximately 4 hours. Two were self-inflicted (a Docker network misconfiguration and a MySQL configuration change that caused OOM conditions). One was an upstream provider incident.
• Infrastructure changes: Adding a new service, updating Nginx configuration, rotating credentials. Roughly 2 to 3 hours per month averaged over the year.
• Monitoring review: 15 minutes weekly, glancing at Netdata trends and checking Uptime Kuma alert history.

Call it 5 to 6 hours per month of genuine infrastructure work. At a conservative consulting rate of $100 per hour, that is $500 to $600 per month in time cost — which immediately makes managed services look economical again. The time cost argument is real and frequently undersold by self-hosting advocates. Whether it applies to you depends entirely on whether those 5 hours represent time genuinely diverted from billable work or whether they happen in margins that would otherwise be unproductive.

The calculus also changes with scale. One server running four services: 5 to 6 hours per month. Two servers running eight services: not 10 to 12 hours per month. The second server adds maybe 2 additional hours if you have already automated backup, monitoring, and update processes. Infrastructure management does not scale linearly with server count up to the point where you genuinely need a dedicated operations function.

When You’ve Actually Outgrown the Single Server

The indicators that a single-server setup is no longer appropriate are specific and measurable. Vague feelings of anxiety about “what if traffic spikes” are not indicators — they are a symptom of unfamiliarity with your own traffic patterns.

Real indicators:

• Sustained CPU above 60% for more than 4 hours per day. Not peak — sustained. Peaks are expected and normal. Sustained high CPU means you are regularly bumping against the ceiling and the next spike will cause visible degradation.
• Available RAM below 2 GB at typical load. This removes your buffer against traffic spikes and large database queries. When the OOM killer starts touching processes, it is already too late.
• Database query latency above 50ms at p99 under normal load. Slow queries at the 99th percentile under ordinary conditions indicate either schema problems or resource contention. On a shared server, resource contention from other services is a legitimate cause that cannot be tuned away.
• Revenue impact from a single-server outage exceeds $500. At this point the insurance value of redundancy changes the calculation. A second server or a managed failover setup pays for itself in risk reduction.
• Compliance requirements. PCI DSS, HIPAA, and SOC 2 compliance demands create audit and configuration management obligations that add genuine operational overhead. Managed services often include compliance tooling that would take weeks to implement correctly on bare metal.

Premature vertical scaling — moving from a $50 to a $100 server because growth feels inevitable — is a common and expensive mistake. A $100 server doubles the monthly cost but rarely doubles performance for typical web workloads, because most WordPress and Node.js serving bottlenecks are I/O-bound, not CPU or RAM-bound. Before scaling up, profile where the actual constraint lies.

When Managed Services Win

There are conditions where managed services are unambiguously the right choice, and pretending otherwise does not serve anyone.

If your Node.js applications process user-uploaded files, handle payments, or run background jobs that could block the main event loop for seconds at a time, the blast radius of a runaway process on a shared server is large. Managed container platforms isolate failure by default. You pay for that isolation, and in these cases the payment is rational.

If you are not the person who will maintain the server — if this is infrastructure for a client, a small business, or a team member who will eventually need to operate it without you — managed services dramatically reduce the bus factor. A Kinsta-managed WordPress instance that a non-technical operator can manage through a control panel is worth considerably more than a self-hosted server requiring SSH access and comfort with Nginx configuration.

If your product is early-stage and your time is the actual constraint, the $30 saved monthly on infrastructure is not meaningful compared to the 5 to 6 hours of maintenance time. Build the product first. Optimize infrastructure when the revenue justifies the optimization.

The $50/month VPS is not a philosophy. It is an engineering trade-off that makes sense under specific conditions: stable traffic patterns, technical operator availability, workloads without hard isolation requirements, and a monthly infrastructure budget where the savings materially affect the business. Recognize those conditions in your own situation before committing to either extreme.

The right infrastructure is the infrastructure that fits your operational capacity. A single well-managed VPS running reliably is a better outcome than a distributed cloud stack that no one on the team fully understands.

The server has been running for fourteen months. The bill has not changed. The applications have not changed in how they behave. I have not thought about the infrastructure on most days, which is the goal. That is the argument for consolidation — not ideology, just a quieter operations calendar and a smaller invoice.