A self-hosted n8n instance is ready for business use when you can prove three things: it completes the intended work, someone notices when it stops, and you can recover without losing or duplicating customer actions. Opening the editor in a browser proves none of those on its own.
This matters when n8n connects forms, a CRM, calendars, documents, or AI tools. A workflow can become part of your operating process long before anyone formally assigns responsibility for it. The person who built the first useful automation becomes the person everyone calls when an expected record disappears.
Use this checklist before moving a meaningful business process onto your own infrastructure. It is an operational review, not a universal deployment recipe. Configuration depends on your installed version, workload, and hosting environment.
What the Reddit conversation gets right
The useful lesson from production stories is that maintenance becomes part of the product.
In an r/n8n thread about running six clients on one server, the author reported operating that setup for about seven months. They described growing execution data, competing workloads, credential recovery concerns, and missed leads. These are self-reported incidents, not independently verified performance results.
The comments made the discussion more useful than the original checklist. u/Ok-Engine-5124 pointed out that an internal error workflow cannot be the only warning mechanism if the application process is gone. u/john_wink1988 recommended tracking the last execution and result so missing work is visible even when nothing throws an error. Other commenters questioned the shared-client architecture and licensing.
Those objections lead to better acceptance tests. Can an external monitor detect an unavailable process? Can the team see a workflow that has not run? Does the hosting arrangement fit the actual license and access requirements?
They do not justify copying every technical statement from the post. Some need qualification, and one conflicts with current documentation.
First correction: inspect retention, do not assume it
Current n8n documentation says execution pruning is enabled by default. The Reddit post's claim that the default keeps every execution forever should not be repeated as current guidance.
The documented defaults include an age threshold of 336 hours, or 14 days, and a count threshold of 10,000 executions. Pruning can be triggered by either limit; certain execution states and annotated executions have additional treatment. Check the documentation and effective settings for your installed release. n8n execution-data documentation
The practical problem still exists: retained data consumes storage, and your configuration may differ from defaults. Decide what you need for debugging, customer support, and audit purposes. Keep that decision separate from a desire to retain everything just in case.
Measure storage growth under representative load. Include attachments and large payloads, not only small test messages. Record how much diagnostic history you can reasonably keep and what evidence must be stored elsewhere before pruning removes it.
A retention policy should answer both questions: how will you investigate yesterday's failure, and how will you avoid keeping unnecessary customer data indefinitely?
Check 1: prove you can recover credentials and data
A backup is useful only if it can restore the working system you depend on.
n8n generates an encryption key on first launch and uses it to encrypt credentials stored in the database. Its documentation explains where the key is stored and how a custom key is configured. That makes the key a recovery dependency, not an optional detail. n8n encryption-key documentation
Your recovery inventory should include the database, required persistent files, encryption key, deployment configuration, and a record of the installed version. Keep secrets in an appropriate protected store, not pasted into the runbook.
Run the restore in an isolated environment. Disable production triggers and outgoing customer actions before starting the restored instance. Otherwise a successful recovery drill can accidentally send old messages or duplicate tasks.
Verify that workflows load, required credentials can be used in a permitted test, and a representative task completes. Record how long recovery takes. Choose an acceptable recovery time based on the business process rather than assuming that “daily backups” settles the question.
Check 2: verify the public path into the workflow
Test the production endpoint from outside the server, using the same path a real event will take.
A reverse proxy, DNS record, certificate, and application configuration all sit between a form submission and the workflow. The editor being reachable does not prove an external webhook is registered correctly.
n8n's current reverse-proxy documentation describes explicitly configuring the public webhook URL. It also notes a version-specific transition: N8N_WEBHOOK_URL replaces WEBHOOK_URL from version 2.35.0. Use the setting documented for your installed release rather than changing variables from memory. n8n reverse-proxy guidance
Test a normal request, a missing required field, and a repeated request. Verify the resulting CRM record or task, not only the HTTP response. Then repeat the normal test after a controlled restart.
Write the expected production endpoint into the handover documentation. Distinguish it from a temporary test endpoint so another employee does not connect the live website to the wrong URL.
Check 3: monitor failures, absence, and final outcomes
Use three different signals because they detect different problems.
| Signal | What it can reveal | What it cannot prove |
|---|---|---|
| External health check | Application or endpoint is unavailable | A CRM record was created correctly |
| Workflow error alert | An execution reported failure | An expected trigger ever arrived |
| Business reconciliation | Expected work is missing or mismatched | The precise technical cause without investigation |
n8n supports error workflows beginning with an Error Trigger, and the same handler can serve multiple workflows. Use those alerts to identify failed executions and their context. n8n error-handling documentation
Add an independent availability check. Then compare inputs and outputs for important processes. If twenty accepted forms arrived today, how many matching CRM records exist? Which ones are intentionally waiting for review? Which have no explanation?
This is where the Reddit comment about the last successful execution is useful. An automation that has quietly stopped receiving work may have no error to report. Record the last expected event and last confirmed outcome, with a cadence appropriate to that workflow.
Do not alert every employee for every temporary retry. Choose an owner and distinguish a recoverable warning from a task requiring intervention. Otherwise a busy notification channel can become another place where failures disappear.
Check 4: make retries safe
A repeated event should not create repeated business actions.
Imagine a form submission creates a customer record, but the response times out before the sending system receives confirmation. It retries. Without a stable event identifier and a duplicate check, the second delivery can create another customer or another follow-up task.
Design the workflow to recognize the original event. Keep a mapping from source event to resulting record or action. If the action already happened, report that result rather than applying it again.
This is often called idempotency: repeating the same request should not multiply its effect. The implementation depends on the connected systems, but the acceptance test is straightforward. Send the same permitted test event twice and inspect the destination.
Also test partial completion. Creating a CRM record might succeed while task assignment fails. A retry should resume or repair the unfinished part, not blindly repeat the whole chain.
If your automation connects customer operations, document which system owns each field. Our guide to CRM integration with two-way QuickBooks sync addresses the related problem of competing records. A successful connection is not the same as a reliable synchronization policy.
Check 5: use measurements to decide on queue mode
Queue mode can separate receiving work from executing it, but it adds components you must operate.
n8n describes a main instance, Redis as a broker, workers that execute jobs, and a database that persists the workflow data. The documentation also notes that dispatching work through the queue can add overhead and latency. It is not a universal speed upgrade. n8n queue-mode documentation
Measure concurrent workload, execution duration, resource consumption, and waiting time before deciding. A slow external API call and a memory-heavy file transformation are different problems. Adding workers without understanding the bottleneck may simply move it to the database or another service.
Test your busiest plausible period, including large inputs and slow dependencies. Keep customer commitments out of the load test by using isolated records and controlled destinations.
For shared environments, decide what one workload is allowed to consume and how a failure affects others. Separate clients or teams where the consequences and access requirements demand it. Isolation is an architectural decision; it should not be left to the naming of workflow folders.
Check 6: assign ownership beyond the server
List every external account the workflow relies on and who maintains it.
A healthy n8n server cannot rescue an expired connection, a removed employee account, a renamed CRM field, or an API permission that no longer grants access. The application and the surrounding business systems need one joined-up handover.
| Responsibility | Required handover detail |
|---|---|
| Hosting | Owner, access route, and support contact |
| Credentials | Approved storage, rotation owner, and affected workflows |
| Connected applications | Account owner and required permissions |
| Workflow logic | Purpose, expected inputs, and business reviewer |
| Monitoring | Alert recipient and escalation path |
| Recovery | Restore procedure and last successful test |
| Changes | Who can edit, approve, and deploy |
Use accounts and permissions appropriate to the organization. Avoid leaving a critical workflow dependent on a contractor's personal login without an agreed transfer plan.
The person answering “who fixes it?” does not have to do every task. They do need to know where responsibility goes when the failure crosses two suppliers.
Check 7: review the hosting and license model
Confirm that the way you deliver the service fits the license, especially when client credentials are involved.
The Reddit comments disagree about exactly where the line falls. Use the vendor's guidance rather than treating those comments as a ruling. n8n's help centre distinguishes consulting on a client's own instance from hosting client workflows and credentials inside your own instance; it describes commercial licensing for the latter and directs specific questions to its licensing team. n8n licensing help
Record the applicable arrangement before choosing a shared architecture. Do not assume that access to source code means every resale, embedding, or hosting use is unrestricted.
This review also clarifies ownership. If the relationship ends, who receives the workflows, configuration, operational notes, and data? A technically recoverable service can still be difficult to hand over if those responsibilities were never agreed.
Check 8: rehearse upgrades and rollback
Treat an upgrade as a change to a business dependency, not a routine click performed without a test.
Record the installed version. Review changes that affect your nodes and integrations. Test a representative set of workflows in a separate environment, including exceptional inputs and external failures.
Before changing production, know how you will recover if behaviour changes. A database migration can make rollback more complicated than replacing a container image, so verify the version-specific procedure and backup plan.
Your regression set should include the workflow that creates the most important customer action, not only the easiest internal notification. Preserve failed cases as future tests. Over time, this creates a useful record of the ways your actual business inputs differ from a tutorial.
If n8n connects your CRM to the rest of the business, bring the workflow and its failure history. We can discuss a maintainable integration with clear ownership and recovery steps.
A go-live exercise your team can run
Run one end-to-end rehearsal and record the evidence against each requirement.
Start with a permitted test request. Confirm it reaches the production-shaped endpoint, creates the correct destination record, and records completion. Repeat the event and verify that no duplicate action appears. Temporarily make a test dependency unavailable and check the alert, retry behaviour, and eventual recovery.
Then run a restore drill separately, with external actions disabled. Ask someone other than the original builder to follow the runbook. Every undocumented assumption they encounter belongs in the handover.
An illustrative scorecard might contain twelve requirements. If eleven pass and the remaining failure is credential recovery, the system is not “92% ready.” Weight the requirements by consequence. A missing optional dashboard label and an untested restore are not equivalent.
Choose the smallest first workflow that produces useful work while keeping the consequences manageable. If you are still deciding whether that workflow needs an agent at all, review our AI agent versus workflow guide.
Self-hosting can be a sound choice when the operating responsibility is deliberate. The production milestone is a system your team can observe, restore, and maintain, not a screenshot of a successful execution.