Workflow Automation

Self-hosting n8n on a VPS: a pragmatic guide for SMBs

Why you'd self-host, what it costs (₹500 a month and an hour), the five things that go wrong, and when you should stay on cloud n8n instead.

15 May 20269 min readKrypto Forge

We run n8n on our own VPS for several clients. The economics are not close. A ₹500/month box can host workflows that would cost ₹30,000+/month on Zapier or n8n Cloud at the same volume. The catch: somebody has to keep the box alive, and most introductions skip the parts where things go wrong.

This is the field guide we wish we'd had. It's specifically for Indian SMBs, but the patterns travel.

Why self-host at all

Three reasons make this worth doing. If none apply, stay on cloud.

Data sovereignty. Customer data, GST data, banking flows. If any of that has to stay on your infrastructure (RBI sectoral guidance, internal policy, a customer contract), you don't have a choice. Self-host or write custom.

Cost at volume. Once your monthly Zapier or n8n Cloud bill crosses about ₹30,000, the math flips. A ₹500/month VPS plus an hour of maintenance per month is cheaper, and the cost is flat against volume. The first time you run a 100,000-trigger month, you'll be very glad.

Integration with internal systems. Self-hosted n8n on the same network as your Postgres, your file shares, your internal HTTP services. No firewall holes. No "we need to expose this API to the internet". That's a meaningful security simplification.

What it actually costs

A real budget for an SMB-grade install:

  • VPS: ₹400-600/month (DigitalOcean, Hetzner, Contabo at the cheap end; AWS or Azure if you must).
  • Domain: ₹800/year (one-time, amortised).
  • SSL: free (Let's Encrypt via certbot).
  • Backup storage: ₹100-200/month (S3-compatible, or your VPS provider's snapshots).
  • Time: 1 hour of setup, then about 30 minutes a month of upkeep.

Total: under ₹1,000/month, all-in. We've yet to find a Zapier or Make bill that beats this once volume is real.

The setup, in one terminal session

We use Docker because it makes everything reproducible. Here's the shape:

# docker-compose.yml
services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=automation.yourdomain.in
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://automation.yourdomain.in/
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=admin
      - N8N_BASIC_AUTH_PASSWORD_FILE=/run/secrets/n8n_pwd
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD_FILE=/run/secrets/pg_pwd
      - TZ=Asia/Kolkata
    secrets: [n8n_pwd, pg_pwd]
    volumes:
      - n8n_data:/home/node/.n8n

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_USER=n8n
      - POSTGRES_DB=n8n
      - POSTGRES_PASSWORD_FILE=/run/secrets/pg_pwd
    secrets: [pg_pwd]
    volumes:
      - pg_data:/var/lib/postgresql/data

Then an nginx reverse proxy in front (we use nginx everywhere, never Caddy), certbot for SSL, and you're done.

The whole thing fits in a Saturday morning for an engineer who's seen Docker before. For a non-engineer, this is exactly the kind of work a small studio takes on for a one-time fee.

The five things that go wrong

These are the failure modes we've actually hit, ranked by how often we hit them.

One: backups that don't restore. Everyone says they have backups. Almost nobody tests the restore. n8n's data lives in a Postgres database plus a few credentials files. Both need to be backed up, and you need to have actually restored them on a fresh VPS at least once. We do this drill quarterly.

Two: SSL renewal that quietly breaks. Certbot is robust until it isn't. If the renewal hook fails or the cron is missed, the certificate expires and every webhook stops working at 3 a.m. on a Sunday. The fix is to alert on certificate expiry separately from certbot's own logs. Uptime Kuma checking the cert from outside works fine.

Three: workflow ID drift after a migration. If you ever move the n8n install or restore from backup, workflow IDs and credential IDs can shift. Webhooks pointing at the old IDs from upstream services silently 404. Audit webhook URLs after any move.

Four: memory creep on busy workflows. n8n's default Node.js process happily uses 2 GB if you let it. On a ₹500 VPS that's a lot. Set N8N_PAYLOAD_SIZE_MAX and prune workflow execution history. We keep 30 days; older clients keep 90.

Five: timezones in scheduled triggers. Set the container timezone to IST if you're in India (TZ=Asia/Kolkata). The default is UTC, which means your "9 a.m. daily" cron actually fires at 2:30 p.m. and nobody notices for a week.

The 3 a.m. failure is the one to plan for. If your workflow runs while everyone sleeps, you need to know it failed before the next business day starts. Not after.

When you should stay on cloud n8n

Self-hosting isn't always right. We tell clients to stay on n8n Cloud when:

  • The team has nobody who is comfortable with Docker, SSH, or backups.
  • The workflow volume is low and the cloud bill is under ₹10,000/month.
  • The data is genuinely fine to live in a SaaS, and the compliance answer is straightforward.
  • The team is going to grow fast and prefers operations as a line item, not a chore.

Cloud n8n costs more per workflow than self-hosted but the total cost of ownership (including the hour you didn't spend on SSL renewal) can be lower for small teams.

What we actually do for clients

The shape we offer most often: we set up self-hosted n8n on a VPS, give the client the credentials, hand over the runbook, and stay on a low retainer to handle the 30-minute-a-month maintenance and any new workflows. After a year, the client either keeps us on or hires internally.

It's not glamorous infrastructure. It's the same recipe applied carefully, every time. That's the part the marketing pages skip.

The honest summary

Self-hosting n8n in 2026 is a solved problem for anyone who can read a docker-compose file. The reasons to do it are data sovereignty, cost at volume, and internal integration. The reasons not to are team capability and operational appetite.

If you'd rather pay Zapier or n8n Cloud and never think about it again, that's a legitimate choice. If you'd rather pay ₹500/month and own the thing, here's the recipe.

Cheap infrastructure is only cheap if somebody is watching it.

Tags

  • n8n
  • self-hosting
  • vps
  • docker
  • ops