Implementation guide
Deploy n8n on a VPS without exposing your automation stack.
This guide describes the production posture DCSS prefers for a small self-hosted n8n deployment: Docker, Postgres, localhost bindings, a single reverse proxy, clear backups, and public exposure limited to intentional webhook paths.
Who this guide is for
- Operators who are comfortable managing a Linux VPS and Docker.
- Small teams that want private workflow automation without giving every workflow to a hosted SaaS account.
- Builders who need webhook, email, database, API, and AI workflow steps in one operational layer.
Who should not self-host yet
- Teams without anyone responsible for updates, backups, logs, and restore testing.
- Workflows with compliance requirements that have not been mapped to access controls and audit needs.
- Users who need the simplest possible path and would be better served by n8n Cloud or another hosted automation tool.
Reference architecture
Run n8n and Postgres on a private Docker network. Bind the n8n editor to localhost on the host, then let the existing reverse proxy handle TLS and public routing. Expose only the webhook paths that must be public, and block or authenticate everything else according to the risk of the workflow.
| Layer | Recommended choice | Reason |
|---|---|---|
| Runtime | Docker Compose | n8n officially recommends Docker for most self-hosting needs, and it keeps the runtime isolated from host package drift. |
| Database | PostgreSQL | SQLite can be acceptable for local testing, but production automation should use a database with clear backup and restore procedures. |
| Reverse proxy | Existing Caddy/Nginx/Traefik layer | Do not introduce a second public proxy if the VPS already has one handling TLS and host routing. |
| Secrets | n8n credentials and protected env files | Workflow JSON and Git history should not contain API keys, webhook secrets, OAuth tokens, or passwords. |
Deployment checklist
- Update the VPS and install Docker from a trusted package source.
- Create a Docker Compose file with `n8n`, `postgres`, and any isolated worker services.
- Bind n8n to `127.0.0.1` on the host unless there is a deliberate private network route.
- Set `WEBHOOK_URL`, editor base URL, timezone, encryption key, database credentials, and runner settings through env files.
- Put public traffic behind the existing reverse proxy and validate the proxy config before reload.
- Back up Postgres, n8n data, workflow exports, and protected env files before major changes.
- Run health checks and one real webhook smoke test after deployment.
Security checklist
- Do not expose Postgres publicly.
- Do not publish the n8n editor without authentication and network controls.
- Validate public webhook input and use shared secrets or signatures where possible.
- Keep `N8N_ENCRYPTION_KEY` backed up with the matching database dump.
- Review workflow exports before committing them, because credentials and private IDs can leak through careless exports.
Rollback procedure
Before a live change, keep a current database dump, workflow export, env/config archive, and the previous reverse-proxy config. If deployment fails, stop the new container, restore the previous Compose or service configuration, reload the known-good reverse proxy config, and verify health before trying another change.
DCSS implementation note
DCSS runs n8n as part of a private VPS automation stack with Docker, Postgres, Caddy, runners, and supporting worker services. This guide reflects that operating model, but it is not a guarantee that the same topology fits every business.
automation
Review n8n options
Compare self-hosting responsibility against n8n Cloud before deciding where your automation should run.
Source notes
This guide was checked against official n8n self-hosting, Docker, Docker Compose, Postgres, and DigitalOcean deployment documentation, then adapted to the DCSS VPS operating pattern.