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.
For teams evaluating n8n on Raff Technologies, the 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 supports both managed and self-hosted deployment models and documents Docker as a supported self-hosting option. A recoverable deployment should preserve the database, instance data, encryption material, configuration, and any custom dependencies required to rebuild the service and use stored credentials again.
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 queue mode, n8n separates the process receiving workflow work from the processes executing that work. Redis participates in queue coordination, worker processes perform executions, and the deployment relies on a shared database and consistent configuration across the participating n8n processes.
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 ↓ Shared database
This model creates additional recovery dependencies. Redis availability, database availability, encryption-key consistency, worker versions, and network connectivity all become part of the system. Check the current n8n queue-mode documentation before implementation because database, licensing, and scaling requirements can change between releases.
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 reports several classes of risk, including credential issues, risky or community nodes, unprotected webhooks, missing security settings, and outdated instances. n8n documents running the audit through its CLI, API, or the n8n node 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;
- persistent instance data;
- the encryption key or equivalent encryption configuration;
- environment configuration;
- custom nodes or dependencies;
- reverse-proxy and DNS configuration;
- external storage configuration where used.
The encryption material deserves particular attention because stored credentials depend on it. A database restore without the correct encryption configuration can leave a restored instance unable to use 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 exposes execution history for troubleshooting, while its security audit can help surface instance-level risks.
Use Cloud Server Backup Strategy for the broader recovery model around VM-hosted services.
Raff Marketplace keeps the first n8n deployment small
Raff currently surfaces n8n through a Marketplace deployment rather than a standalone /products/n8n-vm product page. That gives teams a current deployment path while keeping the architecture centered on the Raff VM that runs the workload.
The important distinction is that Marketplace deployment does not remove n8n operations. The team still owns workflow design, credentials, application updates, monitoring, recovery, and the security of the integrations connected to the instance.
A sensible Raff growth path is:
Stage 1 Dedicated n8n deployment HTTPS + controlled access Backups + failure monitoring Stage 2 Stronger database and recovery ownership Private connectivity to internal systems Stage 3 Queue mode only after measured execution pressure Redis + workers + shared database
Raff VMs can provide the compute boundary for a self-hosted n8n deployment. When n8n needs to reach private application or database services, Raff VPC can provide a private network path between supported resources instead of exposing every dependency publicly. Check the current VM and pricing pages for plan-specific infrastructure details.
Raff Data Protection can support VM-level recovery with snapshots and automated backups; application-aware backups for n8n data and credentials remain part of the workload design.
A self-hosted n8n deployment still needs its own owner and recovery plan regardless of the infrastructure provider.
Actual n8n throughput depends on VM resources, workflow design, external APIs, concurrency, database performance, and the architecture used. Do not treat a Marketplace deployment as a promise of unlimited workflow capacity.
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.
- Encryption configuration 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 private networking, stronger monitoring, database changes, and queue-mode components only when workflow criticality or measured execution demand creates a reason. Keep credentials scoped, protect the encryption configuration, 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.
