n8n is a workflow automation platform with a visual editor and options for technical customisation. A workflow connects triggers, data transformations and actions in other systems. It can be self-hosted or used through a hosted offering, subject to the relevant terms.
The useful question is whether it fits a defined process and whether someone can operate the resulting workflow reliably.
Source-available licensing
n8n makes source code available under licence terms that include the Sustainable Use Licence. This is different from an unrestricted open-source licence. Permitted internal use, commercial features, embedding and services offered to others should be checked against the current terms.
Do not assume that a particular number of users automatically requires a particular commercial plan. Review the actual use and licence conditions in the n8n documentation.
How a workflow is organised
A typical workflow contains:
- A trigger: a schedule, webhook or supported application event.
- Input handling: validation, filtering and mapping of the incoming data.
- Actions: reading or updating an application, preparing a document or calling a service.
- Decisions and exceptions: branches, approval steps and failure handling.
- Execution records: enough information to monitor and investigate the run.
The available nodes and their behaviour depend on the installed version and configuration. A visual editor reduces some coding work, but it does not remove the need to understand APIs, data types or permissions.
An illustrative enquiry workflow
An incoming enquiry could be checked for required information, recorded in a CRM and assigned to a person. An AI step might prepare a reply draft for review.
Before automating the process, define what happens with duplicate messages, missing details, unavailable services and uncertain classifications. Sending a draft or changing a customer record should require the permissions and approval rules agreed for that action.
This is a possible design, not a measured client deployment or a claim that the necessary connectors are available for every system.
Hosted or self-hosted
A hosted service can reduce infrastructure work, but the team still owns workflow logic, credentials, data handling and business decisions. Check limits, supported features, data locations and contractual arrangements for the selected plan.
Self-hosting offers control over the application environment while adding responsibility for:
- installation and supported upgrades;
- authentication, network access and secrets;
- backups and tested recovery;
- monitoring, storage and execution retention;
- capacity planning and incident response.
A self-hosted workflow can still send data to external APIs or model providers. It does not mean that data never leaves the server or that regulatory requirements are automatically met.
Plan cost and capacity
Include the applicable licence, infrastructure, databases, backups and staff time. Workload depends on the actions performed, payload sizes, concurrency and external dependencies. A count of executions alone does not determine the resources needed.
Test representative workloads and failures before setting capacity expectations. If a queue or worker architecture is considered, assess how it affects deployment, monitoring and recovery using the current documentation.
Using AI in a workflow
A workflow can call a model for tasks such as extraction, classification or drafting. The model’s output needs validation appropriate to the action that follows.
Keep the boundaries explicit: what data can be sent, which tools may be called, when a person must review the result and how unsupported requests are handled. A model selecting an action is not evidence that the action is authorised or correct.
Installation and production preparation
Use the current hosting documentation for supported installation and configuration instructions. A short container example is not a complete production setup, especially when it exposes an application publicly or uses outdated authentication settings.
Start in a controlled test environment with non-sensitive sample data. Configure access, credentials and retention before connecting real business systems. Record how updates and recovery will be handled.
A useful first test
Choose a low-impact workflow, such as reading approved sample records and preparing an internal report for review. Test normal inputs, missing fields, duplicate events and a failed dependency.
Check the execution record, verify the output and confirm that a repeated run does not create duplicate actions. Define a person who owns alerts and can pause the workflow.
Migration from another platform
Inventory each workflow’s triggers, actions, mappings, credentials and exception paths. Check whether the required operations exist in n8n or need custom work.
Compare outputs and failure behaviour before switching. Plan how to avoid duplicate events or missed work during the transition. Migration cost and duration depend on that scope; no fixed proportion of connectors or automatic payback should be assumed.
FAQ
Is n8n open source?
It is source-available under its applicable licence terms, including the Sustainable Use Licence. Those terms differ from unrestricted open-source licences and should be reviewed for the intended use.
Is self-hosted n8n free to operate?
No. Even where the licence permits the intended use without a software fee, infrastructure, updates, backups, monitoring and staff time still have a cost. Some features or uses may require commercial terms.
Does self-hosting keep all data local?
Not automatically. Workflows can call external applications, models and services. Review the configured data flow, logs, telemetry options and retention before handling sensitive information.
Do we need a developer?
That depends on the integrations and logic. Technical help may be needed for custom operations, security, failure handling and self-hosting. The business process owner should remain involved even when a specialist builds the workflow.
Can n8n handle our workload?
Evaluate the actual workflow under representative volume and failure conditions. Capacity depends on infrastructure, configuration, payloads and external services; there is no universal execution limit or performance guarantee for every deployment.
Discuss the process first
Within Q-Journey, AiP can examine a business process through an individually agreed scope. Application development following the audit belongs to Q-Journey’s second stage. A defined workflow requirement can also be discussed through Q-Dev.