Hire n8n developers who will tell you when n8n is the wrong answer.

Start with the encryption key, because the most common way a self-hosted instance dies has nothing to do with workflows. On first boot n8n writes a key into its home directory and encrypts every stored credential with it. Run the container without a persistent volume mounted at that path and the next restart generates a fresh key, at which point every credential in the database is ciphertext nobody can read. We set N8N_ENCRYPTION_KEY explicitly from your secret manager on day one and treat it like a database password, because losing it costs about the same.

Second, know what the licence actually is before you commit to self-hosting. n8n is fair-code under the Sustainable Use Licence, not OSI open source. Internal business use is fine; reselling it as your own hosted product is not. And the features an enterprise tends to assume are included sit behind a paid licence: single sign-on, git-backed environments, external secrets, log streaming. Self-hosting saves you per-execution pricing. It does not automatically save you a licence fee, and a procurement team finding that out in month four is not a pleasant meeting.

Third, we start in queue mode rather than arriving at it later. Out of the box n8n executes workflows inside the same Node process that serves the editor. One workflow doing a synchronous transform over twenty thousand items will block the event loop, and the symptom your team reports isn’t “the workflow is slow,” it’s “the canvas has frozen.” Setting EXECUTIONS_MODE=queue with Redis in front and separate worker containers costs an hour in week one and is miserable to retrofit during an incident. Worker concurrency then becomes a real number with real consequences: set it high against a rate-limited API and you’ve built a distributed way to generate 429s.

Fourth, the execution table is what takes most instances down. Every run persists its per-node input and output data, on success as well as on failure, and by default into SQLite. A workflow firing every minute with a moderately fat payload will put tens of gigabytes in there inside a quarter, and by the time anyone looks, the pruning job is competing with live traffic on a database that can no longer breathe. So we run Postgres from the start, configure retention and max-age pruning before launch, turn saving on success down for high-frequency workflows, and move binary data to filesystem or S3 so a 40MB PDF isn’t copied through execution history at every node it passes.

Fifth, retry and recovery are different things, and n8n makes them easy to confuse. Per-node retry with a wait between attempts handles a flaky endpoint well. It does nothing about the case that hurts, which is a workflow failing at node nine after node four already created a record; re-running from the start creates it again. So anything that writes gets an idempotency key or a lookup-before-insert, and the steps nobody can make idempotent get isolated into their own sub-workflow with their own error branch. We set the error workflow at instance level rather than per workflow, so a new automation cannot ship silently unmonitored.

Sixth, most requests for a custom node don’t need one. The HTTP Request node with a generic credential will talk to your internal API today, costs nothing to maintain, and needs no republishing when that API changes. A custom node earns its keep when the integration goes to people who should never see a header, when auth or cursor pagination is fiddly enough that repeating it across a dozen workflows becomes a liability, or when you want the thing callable as a tool by an agent. When we do build one, declarative style suits a well-behaved REST surface because there’s far less to break, and programmatic style is for binary handling or a token refresh quirk that needs real control.

A last one, procedural rather than technical. A workflow living only on a canvas isn’t under source control, and the feature that fixes that properly sits on the paid tier. Where that licence isn’t in the budget, we export workflow JSON into your repository and review changes as diffs. It’s uglier than it sounds useful, and it means somebody can answer what changed on Tuesday. Either way the rule holds: you deploy to production, you do not edit in it. Two adjacent decisions come up on nearly every engagement, and settling them before kickoff saves a fortnight. Where the confidence threshold sits, and whether the retrieval step needs RAG or a fine-tune, which is almost always retrieval.