Orchestrating a Single Node: When One Machine Is Enough

Most small applications are one or two services with a database and are far too small for a cluster. Forcing them into Kubernetes on one machine adds a control plane that competes with your app for memory and a lot of operational surface with little payoff. A single well-organized node — one VPS running several containerized services behind a reverse proxy — is a legitimate, boring, reliable architecture.

This post shows how to treat one machine as a small platform with restart policies, a shared network, TLS, and backups.

Why One Node Is a Real Architecture

A single node removes the hardest parts of distributed systems: there is no leader election, no split brain, no service-to-service networking beyond localhost, and no scheduler to babysit. What you lose is horizontal scaling and node-level redundancy, which many workloads never actually need at the sizes where they live. You gain simplicity, predictability, and near-total control of the host.

Keep the node disciplined instead:

• Every service is a declarative unit (Compose or a Quadlet).
• Only the reverse proxy publishes a public port.
• Everything runs non-root and read-only where possible.
• Backups are automated and tested.

A single host running several services, each isolated and quietly self-managed.

Compose as the Single-Node Orchestrator

Buildah, Podman, and Docker all accept a compose file that defines services, networks, and volumes as one unit. That file is the single-node orchestration layer:

version: "3.9"
services:
  app:
    image: myapp:1.5
    restart: unless-stopped
    networks: [internal]
    environment:
      - DB_URL=postgres://app@db:5432/app
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    volumes: [pgdata:/var/lib/postgresql/data]
    networks: [internal]
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports: ["80:80", "443:443"]
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddydata:/data
    networks: [internal]
networks:
  internal:
volumes:
  pgdata:
  caddydata:

Deploy with docker compose up -d. Caddy routes public traffic to the internal app service and the database is never exposed.

Health, Logs, and Self-Healing

On one node, systemd and the container engine share the watchdog duty. restart: unless-stopped handles crashes; a probe keeps the proxy only routing to healthy instances if you run more than one replica. Centralize logs to the host so a chatty container cannot fill the disk:

docker compose up -d
docker compose ps
docker logs --tail 100 app
journalctl -u docker --since "10 minutes ago"

Backups Are the Safety Net

No cluster talks you out of backups, so make them explicit. A nightly job dumps the database volume to object storage or another host:

#!/bin/sh
set -e
docker compose exec -T db pg_dump -U app app   | gzip > /backups/app-$(date +%F).sql.gz
find /backups -name "*.gz" -mtime +14 -delete

Schedule it as a systemd timer and restore once into a throwaway instance to prove it works.

When to Leave the Single Node

Move off one node when you genuinely need more than vertical capacity, or when you want node failure to cost you nothing. A sensible next step is two nodes behind a load balancer, not a full cluster. Only add an orchestrator like Swarm once three or more nodes earn their control-plane cost.

Takeaway

A single well-run VPS with Compose or Podman Quadlets, a reverse proxy, and tested backups is a complete platform for a huge class of applications — and far easier to reason about than a toy cluster. Put yours on an instance from Netbay in the Lucknow DC01 datacenter, netbayhosts.in, and the whole stack deploys with one compose command.