How I Deploy Automation Systems on a VPS

Building an automation workflow is one thing. Running it reliably in production, where it needs to survive server reboots, handle errors gracefully, and not silently fail at 3am, is a different problem. Here's the actual architecture I use.

The Stack

• VPS — dedicated resources, full root access, typically Ubuntu or Debian
• Docker — every service (n8n, database, reverse proxy) runs in its own container
• Nginx — reverse proxy handling SSL termination and routing
• PostgreSQL — persistent storage for workflow data and execution history
• Domain + SSL — proper HTTPS via Let's Encrypt, not a raw IP address

Why Containerize Everything

Running n8n (or any automation platform) directly on the host operating system works — until a system update breaks a dependency, or you need to run two different versions of something for different projects. Docker isolates each service so they don't interfere with each other, and makes moving the entire setup to a new server a matter of copying config files, not reinstalling everything from scratch.

Persistent Storage Matters

Automation platforms store workflow definitions and execution history in a database. If that database lives inside an ephemeral container without a persistent volume, a container restart can wipe your workflow history. Every production deployment I build mounts the database to persistent storage on the VPS, separate from the container lifecycle.

Monitoring and Alerts

An automation that fails silently is worse than one that never ran — you think it's working when it isn't. Production deployments need: error notifications (Slack, email, or WhatsApp) when a workflow fails, basic server health monitoring (CPU, memory, disk space), and uptime monitoring on the automation platform itself.

Backups That Actually Restore

Automated daily backups of the database and configuration, stored somewhere other than the VPS itself (so a server failure doesn't take out your backups too). I test restores periodically — a backup you've never restored from is a backup you don't actually have.

Security Basics

Firewall rules limiting access to only necessary ports, SSH key authentication instead of passwords, regular system updates, and credentials stored in environment variables rather than hardcoded into workflows. None of this is exotic — it's just easy to skip when you're focused on getting the automation working.

Where Hostinger Fits

For most small-to-mid-size automation deployments, a mid-tier Hostinger VPS plan (KVM 2 or above) has enough RAM and CPU to comfortably run n8n, a database, and a reverse proxy together. It's one of the providers I use for client deployments when the client doesn't already have infrastructure in place.

Frequently Asked Questions