n8n development: workflows you can host and read

n8n suits teams that want control over where their workflows run:

• You want to self-host on your own infrastructure, on-premises or in a private cloud, for example to keep data close to your other systems.
• Your workflow needs real code. The Code node runs JavaScript or Python, and a self-hosted instance can import npm modules.
• The workflow is part of a larger system. n8n can call your API endpoints and you can keep heavy logic, such as SQL, in your own code.
• You want AI steps beside ordinary ones. n8n connects to several model providers and gives agents tools and memory.

Check these before you commit:

• Nobody will run the server. n8n's docs say self-hosting needs technical expertise for installation and configuration. n8n Cloud removes that, but limits customization to the options n8n offers.
• You need external npm modules on n8n Cloud. The Code node there cannot import them.
• You plan to offer n8n itself to others as a paid service. The Sustainable Use License limits use to your own internal business purposes or non-commercial or personal use, so read the license first.
• The task is a simple link between two popular apps. A hosted tool such as Zapier or Make may be quicker to set up and hand over.

A workflow is a set of nodes connected on a canvas. A trigger node starts it. The Webhook node gives you a test URL for building and a production URL that registers when you publish the workflow. It supports basic, header and JWT authentication and an IP allowlist, and it can respond immediately, when the last node finishes or through a Respond to Webhook node. The Schedule Trigger runs on intervals or a cron expression, in the workflow's timezone. Each run is an execution, and you can see executions per workflow or across all of them. Credentials hold the login details for the services you connect, and you can restrict which domains a credential may be sent to. The Code node runs JavaScript or Python, once for all items or once per item. It cannot make HTTP requests or touch the file system, so the HTTP Request and file nodes do that. We have also connected n8n to an eCommerce store's marketing tools.

Not sure which tool fits? See how we choose between Zapier, Make, n8n and custom code.

• Error workflows: an error workflow starts with the Error Trigger and runs when an execution fails. One can serve many workflows. It receives the execution ID, the error message and the last node that ran. A Stop and Error node can fail a run on purpose when your own checks fail.
• Node settings: Retry On Fail reruns a node that fails, and On Error lets a node stop the workflow, continue or send the error down a separate output. We choose these per node instead of leaving defaults.
• Scaling: in queue mode the main instance handles timers and webhooks and creates executions, Redis queues them and workers run them. Workers need the database and the main instance's encryption key. Queue mode is not supported on SQLite. Separate webhook processors can sit behind a load balancer for heavy webhook traffic.
• The license: n8n's Sustainable Use License allows use or modification for your own internal business purposes or for non-commercial or personal use. It allows distribution only free of charge for non-commercial purposes. Files marked as enterprise need an n8n Enterprise license.
• Ownership: the server, the credentials and the workflows belong to you, with the workflow logic documented.

1. Choose where it runs: n8n Cloud or self-hosted, based on who will run the server and what the Code node needs
2. Keep heavy logic in code: SQL and business rules live in your own code and database, and n8n orchestrates
3. Add error handling from the start: an error workflow, retry settings per node and an alert to the people who fix things
4. Hand over properly: the hosting, credentials and workflows documented, with notes on reading a failed execution