Decide whether you can operate the design
Fit when ownership and recovery are explicit
Self-hosting gives you control over where the core application runs and how its surrounding services are arranged. That does not make every capability part of the same free feature set: edition and license gates, external services, and operational responsibilities still need separate decisions. Identify a person who can patch the operating system and application, protect the encryption key, review public exposure, monitor failures, and make a restore decision.
A fit does not require knowing every future workflow in advance. It does require a bounded discovery plan: record trigger types, data shapes and execution classes; observe representative runs; and revisit the component map when those observations change. If Docker Compose is the intended packaging route, use the Compose baseline decision. If an image or one-click package is being considered, use the packaging responsibility review to identify who owns what after initial setup.
Not yet a fit when a dependency has no owner
Do not turn an unknown workload into a precise hardware recommendation. Pause when production work may be heavy or binary-intensive but has no observation window; when the master key or database has no recovery owner; when resident inference shares a host without a resource and network plan; or when the expectation is managed production availability without a named operator.
Queue workers distribute execution work; they do not by themselves provide high availability. A provider snapshot is not automatically an application-consistent, independently restorable copy. If you want no server operations, compare managed routes on their stated boundaries without assuming one vendor's scope. Treat production HA as a separate requirement with explicit failure domains and acceptance evidence.
Start with workload, release and recovery intake
Complete this worksheet before requesting a quote. Write observed values or mark them UNKNOWN; unknown means the architecture is incomplete, not that the missing component can be ignored. The last column routes the unanswered question to the article that owns its deeper decision.
Workload and execution fields
| Field | Your entry | Why it changes the design | If unknown | Route |
|---|---|---|---|---|
| Triggers and workflow pattern | ________________ | Webhooks, schedules, polling and manual starts create different exposure and execution paths. | Inventory workflows and entry points. | Webhook and TLS |
| Execution classes | Production ___; manual ___; sub-workflow ___; error ___; CLI ___; evaluations ___ | Not every kind is governed by the same production concurrency control. | Classify before sizing or adding workers. | Queue and concurrency |
| Concurrency and observation window | Peak observed ___; window ___ | One snapshot cannot represent workload variability or prove throughput. | Collect representative observations. | Execution worksheet |
| JSON and binary shape | Typical/max items ___; binary count/size ___; retention ___ | Payload copies, binary handling and retention affect memory, storage and supported topology. | Measure representative runs and retention need. | Database and backups |
| Code and community packages | Packages ___; trust owner ___ | Code execution and custom packages add a security and runtime boundary. | Inventory nodes and trust assumptions. | Task runners |
| Expected growth | New workflows/data ___; basis ___ | Growth changes retention, service count and copy capacity; it does not map to a workflow-per-GB rule. | State an observation date and review trigger. | Cost walkthrough |
Use errors, memory symptoms and execution history as observations, not as a benchmark. n8n documents that workflows can hold substantial data and that Code nodes or manual executions can affect memory use; the actual impact depends on the workflow. Keep a record of what was running, its payload shape and which component showed pressure. See the memory troubleshooting guide.
Release, edition and topology fields
Record current and target image tag, source channel, install method and migration history. Also record database type/version; whether Redis and workers exist; whether Code task runners or the Assistant sandbox are needed; and whether multi-main, Git/environments, external secrets or external binary storage is a requirement. Mark each item selected, rejected or unresolved.
latest tag.Queue mode is not multi-main. Edition and activation requirements differ: a feature mentioned in documentation is not automatically included in the deployment or license you selected. The official edition comparison should be checked against the exact feature need. The self-hosted edition comparison describes Community and paid feature distinctions; source control and environments also have their own feature requirements. Keep app licensing separate from host charges.
Data, recovery, network and ownership fields
Write down recovery objectives (acceptable data loss and target recovery time) as goals, not promises. Inventory the .n8n directory and encryption key, database and global objects, binary/execution data, custom paths and external stores, plus configuration, DNS and TLS state. Assign the restore operator and identify an independent copy location. For Docker, the documented container data path is /home/node/.n8n; the real volume or bind name must be discovered in your project.
Record whether each workflow needs inbound access, outbound API access, or both; who controls DNS, certificates, proxy and firewall; and whether optional services share the host or are separate. Include the time budget for patching, observing, recovering and retiring the system. If any row remains UNKNOWN, label the architecture incomplete. JSON exports alone are not a full recovery plan; compare coverage in the export, migration and recovery decision.
Turn intake into components, artifacts and responsibilities
Draw the design as a chain: workload and selected release → processes and services → network and trust boundaries → persistent artifacts → accountable operators → unresolved commercial terms. This map is the bridge from product choice to a provider quote. It prevents a single “VPS” line from hiding a database, object store, external API, or recovery copy.
The dependency-artifact map
Start with the main/editor process. Add webhook processors, Redis and workers only if the selected execution design requires them. A Code task runner is a separate execution boundary and must match the relevant n8n configuration. The Assistant sandbox is yet another service; it is not the same thing as a resident local model. A remote model API is a network dependency, not local inference. Add database, proxy, optional model or vector service, and any selected external store. Draw which components can reach the editor, database, Redis, runner, model, and public network.
Keep four concepts distinct: regular production concurrency controls; Redis queue mode with worker processes; external Code task runners; and the Assistant's Docker-in-Docker sandbox. They solve different problems and carry different privileges and dependencies. The bundled Assistant sandbox documentation's 4 GB RAM and 2 vCPU note is scoped to that bundled Assistant stack; it is not a bare n8n minimum or a general sizing rule. For AI placement and contention, continue to the AI resource decision.
The artifact coverage set
For each selected component, name what must survive a host loss: release and configuration; .n8n including recoverable key material; external database and applicable global objects; binary, execution and custom-node paths; object or model/vector data; user/project state; and deployment, DNS and TLS configuration. Not every topology uses every artifact. Mark not applicable with a reason, and name the store, copy cadence, retention and restore owner for each selected item.
A persistent volume retains data across a container replacement; it is not an independent backup. A database copy without the instance key may not restore usable credentials, and a workflow package does not cover all instance state. Compare the application-specific boundary in database and backup boundaries and recovery coverage. For the provider-neutral distinction between snapshots and independent recovery, read VPS backups versus snapshots.
The responsibility and billable hand-off
Fill one row per component, artifact or obligation. This is a responsibility worksheet, not a price estimate; every unknown commercial inclusion must remain unresolved until supported by provider evidence.
| Requirement | Status | Owner | Placement | Evidence to obtain | Billable? |
|---|---|---|---|---|---|
| n8n main/editor, selected tag | ________ | ________ | ________ | Tag, update and migration boundary | App/license or host: verify |
| Database / Redis / workers / runner | ________ | ________ | ________ | Supported versions, access, storage and owner | Count selected services once |
| Proxy, DNS and public address | ________ | ________ | ________ | Route, renewal, address and firewall terms | Verify inclusions |
| State, copies and restore | ________ | ________ | ________ | Covered artifacts, retention, restore path | Storage, transfer, labor: verify |
| Optional AI, search or external API | ________ | ________ | ________ | Selected service, usage and data boundary | Unselected is excluded; unknown is unresolved |
Mark each alternative selected, rejected or unresolved. Only selected alternatives flow to the cost ledger, counted once. Unknown inclusion is not a zero price. When the architecture is explicit, send this inventory to the n8n total-cost walkthrough and the shared VPS cost tool.
Eight decisions to resolve before comparing VPS offers
Use each route to produce a concrete artifact, then return with it to the responsibility worksheet. These decisions are deliberately separate: changing execution mode does not settle database recovery, and selecting a package does not settle who patches it.
| Decision | Bring this evidence | Why plan size cannot answer it | Decision route and return artifact |
|---|---|---|---|
| 1. Execution and concurrency | Execution classes, observed concurrency, payloads | Workers, regular mode and Code runners are distinct. | Queue and concurrency → execution/dependency map |
| 2. Database and backups | State, retention, consistency and restore owner | DB choice changes state location and copy coverage. | Database and backups → retention/DB-copy worksheet |
| 3. Deployment composition | Versions, services, ports, privileges, volumes | A container list alone does not prove persistence or readiness. | Compose baseline → service/port/volume ledger |
| 4. Webhook and TLS path | Caller, DNS, proxy, certificate, handler | An address alone does not establish a working callback route. | Webhook and TLS → route matrix |
| 5. AI execution and placement | Remote API, Code, sandbox or resident service | These have different network, memory and billing boundaries. | AI resources → co-location choice |
| 6. Package responsibility | Image provenance, updates, existing data and exit | One-click setup describes packaging, not ongoing ownership. | Packaging responsibility → responsibility matrix |
| 7. Secrets and rotation | Key classes, distribution, escrow and revocation owners | Master key, data key and external credentials have separate lifecycles. | Secrets and rotation → key register |
| 8. Export, migration and recovery | Artifacts, version path, target and rollback evidence | Exports, snapshots and full restores cover different state. | Export and recovery → coverage and rehearsal plan |
The cost decision follows the architecture; it is not a ninth implementation theory. Keep Local AI model selection outside this hub. When resident-model research is needed, use the existing Local AI VPS guide.
What to verify with a provider
Take the selected-component map and ask for evidence tied to the exact product, region and billing period. A provider's advertised machine label does not answer whether your chosen services, image path or recovery plan are supported.
Product and billable evidence
- Record the exact product/SKU, operating system, virtualization and region; if your chosen design needs nested/container privileges, ask what is permitted and how that permission is documented.
- Obtain current and renewal cash terms, address and storage charges, backup and transfer allowances, and which events start, stop or continue billing.
- Identify support boundaries: host, OS, packaged image, n8n application, database, proxy and third-party services. Ask who handles each selected component.
- Request written scope for scaling, exporting, stopping and deleting. Keep unknown amounts and inclusions unresolved in the cost worksheet.
Use provider requirements to compare the evidence you collect; this hub does not rank vendors or imply that a named provider supplies a particular image, support level or included service.
Recovery, cancellation and support boundaries
Ask what a host backup captures, how it interacts with a live database, where independent copies can be stored, and how a restore is initiated. Confirm deletion persistence, public-address ownership and change behavior, and the maintainer of any prebuilt image. A “backup included” statement does not establish application consistency or prove a restore.
Review backup and snapshot boundaries and stop, deletion and billing terms. Record the source and date of each answer beside the relevant row. If a term cannot be verified, mark it unresolved rather than assuming it is included.
Problem-handling signals without fake benchmarks
Use symptoms to decide what to inspect, not to infer incidence or rank a provider:
- “Runs fine.” Ask for exact n8n tag, database, execution class, concurrency, payload and observation window. Then compare like-for-like evidence in the execution guide.
- “Out of memory.” Identify the execution and component involved, inspect the data path and measured allocation, and consider reducing data held or changing placement. Do not turn one error into a universal server tier.
- “Still billed.” Check the exact stop, delete, storage and address terms for the selected product.
- “One-click broke.” Discover the image/tag, volumes, environment and update owner before changing state; use the packaging review.
- “Credentials missing after restore.” Inspect key and database coverage, then follow the recovery coverage decision.
For how evidence and problem reports are interpreted, see Methodology. A symptom report is a prompt for inspection, not a failure-rate statistic.
Conditional next steps
- Architecture still unknown? Finish the intake and mark missing observations UNKNOWN. Do not request a precision size until those questions have a bounded discovery owner.
- Release or migration path unresolved? Resolve the exact image tag against its release notes and migration report in the Compose decision before updating a valuable instance.
- Component diagram known? Transfer selected items once into the cost walkthrough and cost tool; preserve unverified terms as unresolved.
- Provider terms still missing? Ask for the exact product, renewal, transfer, backup and deletion evidence through provider requirements.
- Recovery coverage missing? Complete the recovery decision before relying on valuable production state.
Before proceeding, verify that every selected service has a placement, network boundary, persistent-artifact entry, operator and evidence trail. Stop if the key, database or external data cannot be restored by an assigned owner. Continue to procurement only when the unresolved list is explicit.
For site scope and author context, see About.
Sources and updates
Source capture checked 2026-11-06. Release and feature availability can change; confirm the selected tag, its matching documentation and edition before acting.
- n8n: Host n8n — self-hosting and edition overview.
- n8n: Release notes — captured release-note heading labels 3.0 released 2026-10-27.
- n8n: 3.0 breaking changes — captured early-access wording; the channel conflict requires recheck.
- n8n: Queue mode — components, shared key and execution flow.
- n8n: Fix memory issues — workflow-specific memory symptoms and responses.
- n8n: Community edition features — edition capability reference.
- n8n: Backup and restore — application state context; confirm current source path for chosen release.
Last reviewed for this draft: 2026-11-06. This article is an architecture intake and routing guide, not a deployment, restore, performance or security test.