n8n-automation-infrastructure: The Tiny VPS That Acts Like a Private Cloud

A self-hosted automation stack where Coolify, Traefik, Cloudflare, and application-aware backups turn one Hetzner box into a system you can actually run, not just deploy.

8 min read • View on GitHub • More from PekkaSetala

A cutaway view of a single server turned into a compact private cloud. Cloudflare appears as a protective outer shell, Traefik sits at the entry gate, and Coolify oversees n8n, Postgres, Redis, and a backup vault inside. The image explains how one modest VPS can behave like a layered platform instead of a single fragile container host. — One VPS, but with distinct layers for edge, orchestration, service runtime, and recovery.

Key Takeaways

This repo treats restore as the real product, and the backup flow is built to prove it.
The stack separates edge traffic, deployment control, and application data even though it all runs on one VPS.
n8n is given its own isolated service boundary, which makes the automation layer behave like a service instead of a container pile.
The design wins by making private automation recoverable, not by chasing scale.

Most self-hosting projects stop at it runs. This one keeps going. The repo is built around a sharper question: what happens when the box reboots, the database drifts, or the whole server needs to be rebuilt from scratch?

That is why the stack feels more like an operating model than a deployment. Coolify manages the app layer, Traefik owns ingress, Cloudflare masks the origin, and the backup scripts treat the system like something that must survive failure, not just impress on day one.

The real product is the recovery path

The strongest idea in the repository is not n8n itself. It is the discipline around recovery. Backups are application-aware, not just file copies, so the database is dumped while it is live, checksums are generated, and a manifest is written so a fresh machine can be rebuilt with confidence.

That changes the tone of the whole project. A self-hosted stack stops being a toy when the author assumes failure is normal and writes the recovery path as carefully as the install path.

A close-up workbench scene where database records are being stamped, sealed, and packed into labeled crates. A checksum slip and a manifest sheet sit beside a live container, making the backup process feel precise rather than casual. The illustration explains that the repository's backup strategy is application-aware and integrity checked. — Backups are treated like an operational procedure, not a drag-and-drop copy job.

One VPS, three control planes

The stack works because it divides responsibility cleanly. Cloudflare handles the public edge, Traefik decides where traffic goes, and Coolify manages how the services live and restart. None of those layers is doing everything, which is exactly the point.

The same box handles request flow, deployment control, and recovery, but each layer owns a different job.

That separation matters more on a small server than on a big one. On a VPS, every extra responsibility leaks into the others. This repo resists that leak by keeping the edge, the runtime, and the recovery path distinct.

Why n8n gets its own little world

The n8n service is not left floating in a shared pool. It gets its own Postgres instance, its own network boundary, and readiness checks that make sure the workflow engine is actually alive before traffic is sent to it. That is a small amount of plumbing for a lot of reliability.

healthcheck:
  test: ["CMD-SHELL", "wget -qO- http://127.0.0.1:5678/ >/dev/null"]
  interval: 30s
  retries: 10

networks:
  - n8n-network

The pattern is simple and useful: do not expose a service by default, do not call it ready until it answers locally, and do not let every other container on the host poke at its database. That is not overengineering. It is the minimum shape of a service you want to depend on.

A medium-distance scene of an automation line where an image enters one end of a conveyor and emerges as an email on the other end. In between, the payload passes through a search step, an LLM step, and a routing step, each shown as a distinct station. The image explains how the repository's workflow examples prove the platform is useful, not just neat. — The workflows are the proof that this is a working platform, not just tidy infrastructure.

The workflow is the proof

The AI workflow chain makes the architecture feel real. An image comes in, search enriches it, an LLM interprets it, and the result lands somewhere useful, such as Gmail. That is not a lab demo. It is a reason to keep the platform alive.

This is where the repo earns its shape. A private automation stack is only worth the effort if the workflows inside it are valuable enough to protect, and this one clearly assumes that they are.

Why this beats the obvious alternatives

Setup	Cost shape	Privacy	Recovery story	Complexity	Best for
Managed SaaS automation	Predictable subscription, but vendor dependent	Strong defaults, but data leaves your boundary	The vendor owns most of the incident path	Low	Teams that want speed over control
Raw Docker Compose on a VPS	Cheap on paper, expensive in attention	Good only if you build the guardrails yourself	Usually improvised after something breaks	Medium	Tinkerers who enjoy manual ops
Kubernetes homelab	Powerful, but resource hungry and layered	Strong if you keep it disciplined	Can be excellent, but recovery paths get wide fast	High	Platform engineers learning or experimenting
This repo	One modest VPS plus a few deliberate layers	Private by design, with origin masking at the edge	Backup, manifest, and restore are first-class	Medium	Solo operators who want control without chaos

The win is not that this is the cheapest option. The win is that it gives one person a strong operator experience per unit of control. That is a much rarer and more useful achievement than raw scale.

What to steal first

Design the restore process before you call the stack finished.
Split edge traffic, deployment management, and application data into separate responsibilities, even on one server.
Treat health checks, manifests, and checksums as product features, not housekeeping.

If you only copy one idea from this repository, copy the mindset. Build for the day after the failure, not just the day of the launch.