n8n self-hosted automation means running the n8n workflow engine on infrastructure your team controls instead of using a provider-managed n8n runtime. Self-host it when private connectivity, data control, custom runtime behavior, or recovery ownership matters enough to justify operating another production service.
Raff Technologies supports 3,000+ customers and 15,000+ VMs from its US infrastructure. For teams evaluating n8n, our architecture rule is straightforward: once a workflow can change customer data, billing state, infrastructure, or another business-critical system, treat the automation runtime like production infrastructure rather than a convenience tool.
Self-hosting is not automatically the better deployment model. n8n Cloud is often the simpler choice when the main requirement is workflow automation without server ownership. A self-hosted instance becomes more compelling when workflows need private APIs, internal databases, custom nodes, direct network control, or a recovery process owned by the same team that operates the application stack.
This guide explains the decision, the architecture layers that matter, how database and queue-mode choices should follow workload evidence, and how Raff fits the self-hosted model. For deployment steps, use How to Self-Host n8n on Ubuntu 24.04 with Docker Compose.
Self-hosted n8n becomes useful when control is worth operations
n8n combines a visual workflow editor with API calls, webhooks, database access, code, schedules, credentials, and integrations. That makes it useful for workflows that sit between lightweight SaaS automation and fully custom integration software.
The deployment decision is less about feature count than ownership.
| Requirement | Better starting point | Reason |
|---|---|---|
| Simple SaaS-to-SaaS automation | n8n Cloud or another managed tool | Lowest infrastructure burden |
| Private API or database access | Self-hosted n8n | Can run inside the controlled network path |
| Custom nodes or runtime dependencies | Self-hosted n8n | More control over the runtime |
| Sensitive workflow data | Depends on governance needs | Self-hosting adds control but also security responsibility |
| Business-critical workflows | Managed or hardened self-hosted | Recovery, monitoring, and ownership matter more than deployment model |
| Team does not want server ownership | Managed n8n | Self-hosting creates ongoing operational work |
| Growing execution demand | Measure first | Capacity, concurrency, database, and workflow design determine the next step |
Self-hosting is justified when it solves an actual boundary: private reachability, data handling, runtime customization, capacity ownership, or recovery responsibility.
It is not justified merely because the team already knows Docker.
For the broader question of automation versus direct integrations, read MCP vs n8n vs API Integration.
Workflow criticality determines the architecture
Before choosing a VM size, database, or scaling model, classify the workflows themselves.
Use six questions:
- Impact: What happens if this workflow does not run for an hour?
- Data: Does it handle credentials, customer records, billing events, or sensitive internal data?
- Reachability: Does it need public SaaS APIs only, or private systems too?
- Execution pattern: Are jobs occasional, bursty, long-running, or continuously triggered by webhooks?
- Recovery: Which data and configuration must be restored after a failed host or bad upgrade?
- Ownership: Who reviews failures, updates n8n, rotates credentials, and tests recovery?
A useful criticality framework is:
| Workflow class | Example | Operational baseline |
|---|---|---|
| Low impact | Weekly report | Basic monitoring and documented owner |
| Operational | CRM sync or support routing | Alerts, backups, controlled credentials |
| Customer-facing | Onboarding or provisioning | Recovery plan, failure handling, change control |
| Financial or infrastructure-changing | Billing action or server operation | Least privilege, approvals, auditability, tested recovery |
The more a workflow can change important state, the less acceptable silent failure becomes.
At Raff, we would not move directly from a few low-impact automations to a distributed worker architecture. We would first make the single-instance deployment observable and recoverable, then scale only after execution pressure or availability requirements become measurable.
A single n8n instance is the right starting point for many teams
The simplest production-shaped self-hosted architecture is usually one dedicated n8n instance with HTTPS, persistent data, controlled access, backups, and monitoring.
Users / webhook senders ↓ HTTPS entry point ↓ n8n instance ↓ APIs, databases, internal services
n8n officially supports Docker for self-hosting. Its Docker documentation says SQLite is the default database, while PostgreSQL is also supported. Even when PostgreSQL stores workflow and execution data, n8n recommends persisting the .n8n directory because it contains other important instance data such as encryption keys and logs.
The architecture should remain small until there is a reason to add another component.
A single instance is a good fit when:
- execution volume fits comfortably on one VM;
- occasional maintenance is acceptable;
- the team can restore the instance from documented backups;
- webhooks and scheduled jobs do not require separate worker pools;
- the database and filesystem are not showing sustained pressure;
- one clearly named owner is responsible for the service.
Do not place an important n8n deployment casually inside an unrelated application server. A dedicated boundary makes updates, access, monitoring, resource usage, and recovery easier to reason about.
The existing Raff tutorial uses Docker Compose with PostgreSQL for a repeatable deployment path; this guide intentionally stays focused on whether that operating model fits the team rather than reproducing the installation procedure.
Database and queue mode should follow measured demand
n8n can grow beyond a single process, but queue mode introduces a distributed system and should be treated accordingly.
In n8n queue mode, the main instance receives triggers and workflow information, Redis coordinates queued execution IDs, and worker processes perform workflow executions against the shared database. n8n describes queue mode as its most scalable execution model.
n8n recommends PostgreSQL 13+ for queue mode and does not recommend SQLite for a distributed queue-mode deployment. All main, worker, and webhook processes must also share the same encryption key so they can access credentials stored in the database.
Use queue mode when measured needs justify the additional components, such as:
- sustained execution backlog;
- worker CPU or memory saturation;
- long-running jobs blocking other work;
- a requirement to add execution workers independently;
- webhook volume that requires a separate processing tier;
- availability requirements that a single execution process cannot meet.
Do not add Redis and workers only because the architecture appears more mature.
Main n8n instance ↓ Redis queue ↓ Worker processes ↓ PostgreSQL
This model creates additional recovery dependencies. Redis availability, database availability, encryption-key consistency, worker versions, and network connectivity all become part of the system.
For teams that already use infrastructure automation, Infrastructure Automation on Raff explains why each layer should still have one authoritative owner.
Credentials, webhooks, and private systems define the security boundary
An automation platform can accumulate access to email, CRMs, databases, billing providers, cloud infrastructure, internal APIs, AI services, and support systems. That makes credential scope more important than the number of workflows.
Use least-privilege credentials for each integration. A workflow that reads inventory should not receive an administrator token merely because that token is easy to create.
Protect the n8n editor separately from public webhook endpoints. The editor can expose workflow logic, credentials, execution data, and powerful nodes; it should not be casually reachable from the same unrestricted path as a public webhook.
n8n includes a security audit that can report unused credentials, unprotected webhooks, risky nodes, community or custom nodes, missing security settings, and outdated instances. That audit is available through the CLI, API, or n8n itself.
A practical security model is:
Admin users ↓ restricted access n8n editor Public systems ↓ only required endpoints Webhook entry points n8n ↓ private network where possible Internal APIs / databases / services
Do not expose a database publicly simply so an automation workflow can reach it. Put the automation runtime on an approved network path instead.
Custom and community nodes also deserve review because they execute inside the automation environment. Treat them as software dependencies with their own update and supply-chain risk.
Backups and observability make automation recoverable
A self-hosted n8n deployment is not production-ready merely because workflows execute successfully today.
Recovery planning should cover the data that makes the instance usable after a rebuild. Depending on the deployment, that can include:
- the n8n database;
- workflow definitions and execution metadata;
- the persistent
.n8ndata directory; - the encryption key;
- environment configuration;
- custom nodes or dependencies;
- reverse-proxy and DNS configuration;
- any external binary-data storage configuration.
The encryption key deserves particular attention. n8n uses it to protect stored credentials, and distributed processes must share the same key. A database restore without the correct key can leave the restored instance unable to use its saved credentials.
Backups should be tested through a restore, not only reported as successful.
Operational monitoring should include:
- failed executions;
- execution duration and backlog;
- CPU and memory pressure;
- database connectivity and storage growth;
- webhook errors;
- worker health when queue mode is used;
- credential expiry or integration failures;
- disk capacity;
- update status.
n8n also exposes execution history for troubleshooting, while its security audit helps surface instance-level risks.
Use Cloud Server Backup Strategy for the broader recovery model around VM-hosted services.
Raff-specific n8n hosting keeps the starting architecture small
Raff currently offers n8n through a pre-configured marketplace deployment on a dedicated VM. The live product page advertises custom-node support, full data ownership and control, 400+ integrations, and no Raff-imposed workflow or execution caps.
That product positioning changes the self-hosting trade-off: the team can own the runtime and VM boundary without starting from a blank server installation.
Raff’s n8n product page currently advertises 400+ integrations and no Raff-imposed workflow or execution caps.
A sensible Raff growth path is:
Stage 1 Dedicated n8n VM HTTPS + controlled access Backups + failure monitoring Stage 2 PostgreSQL and stronger recovery ownership Private connectivity to internal systems Stage 3 Queue mode only after measured execution pressure Redis + workers + shared database
Raff’s VM platform also provides root access, networking controls, snapshots, backups, and private-network options that can support a production n8n design. Keep those controls proportional to workflow criticality rather than enabling every infrastructure feature on day one.
Raff Technologies supports 3,000+ customers and 15,000+ VMs; an n8n deployment still needs its own owner and recovery plan.
The “no execution limits” product claim should not be read as infinite capacity. Actual throughput still depends on VM resources, workflow design, external APIs, concurrency, database performance, and whether the architecture has moved to queue mode.
Self-hosted n8n readiness is measurable
Before relying on self-hosted n8n for important operations, verify the following.
Ownership
- One person or team owns the instance.
- Workflow owners are known.
- Updates and maintenance have a defined process.
Security
- Editor access is restricted.
- HTTPS is configured.
- Credentials use least privilege.
- Private systems remain private where possible.
- Custom and community nodes are reviewed.
Recovery
- Database and instance data are backed up.
- The encryption key is protected separately.
- Restore steps are documented and tested.
- Recovery ownership is clear.
Operations
- Failed executions generate visible alerts.
- CPU, memory, disk, and database health are monitored.
- Workflow growth and execution pressure are measurable.
- Queue mode is added only when evidence supports it.
Change management
- Important workflows have test cases or validation steps.
- Risky workflow changes have review and rollback paths.
- Credentials and dependencies can be rotated without rebuilding the complete system.
A self-hosted automation platform is ready when the team can explain not only how it runs, but how it fails and how it is restored.
:::cluster
Conclusion
n8n self-hosted automation makes sense when the team needs enough control over private connectivity, credentials, runtime behavior, data handling, or recovery to justify owning the service.
Start with one dedicated, observable, recoverable instance. Add PostgreSQL, private networking, stronger monitoring, and queue-mode components only when workflow criticality or measured execution demand creates a reason. Keep credentials scoped, protect the encryption key, and test recovery before workflows become business-critical.
Continue with MCP vs n8n vs API Integration if you are still choosing an integration model, or use the self-hosted n8n Docker tutorial when you are ready to deploy.