Self-hosted n8n in Australia. Know the whole data path.

Choose the region, then follow the data out

We document the selected infrastructure region and then trace every outbound connection. The CRM may process records elsewhere. An AI provider may receive a document excerpt. Logs or backups may use a separate service and support staff may have access from another location. Each is a separate question for the design and provider terms.

We minimise the fields leaving each boundary and decide whether execution data should be retained, redacted or pruned. If a requirement applies to processing as well as storage, the map needs to cover both. Hosting location by itself is not evidence that the full system meets a residency or legal requirement.

• Application host and database region
• Backup destination, retention and restoration access
• Connected SaaS and model-provider processing
• Execution logs, monitoring and support access

Self-hosting creates an operating responsibility

n8n documents self-hosting on your own infrastructure and distinguishes Community from paid Business and Enterprise editions. We choose the edition around the actual access and operating requirements rather than assume every cloud or enterprise feature is present in Community.

The written operating scope names who manages TLS, patches, credentials, database health, storage, backups and incident recovery. It includes a tested upgrade path and a way back when a version changes workflow behaviour.

Queue mode, workers and additional services are architecture choices for an actual workload, not a default badge of sophistication. Each additional dependency needs monitoring and recovery. We start with the least complicated arrangement that satisfies the capacity and reliability requirements.

Check the licence against how you will use it

n8n is source-available under fair-code terms, not OSI open source. Its Sustainable Use License gives examples that permit internal business use, workflow consulting and maintaining an internal company server. Charging customers to access a hosted n8n service is a different licensing question.

We scope implementation and support in your business’s own environment. If you want to embed or resell functionality, the intended use needs checking against current n8n terms and, where necessary, a separate commercial agreement. Owning your workflows does not override the platform licence.

Use self-hosting for a defined requirement

Self-hosting is a useful option when control of the runtime environment serves a specific requirement and the business can support its operation. That might concern infrastructure ownership, access boundaries or an integration that needs a particular deployment arrangement. We start by writing down the requirement so the proposed architecture can be judged against it.

If the real objective is simply to avoid another subscription, the operating comparison needs care. Hosting, backups, monitoring and operator time still exist. Your team may already have suitable infrastructure and skills, or those capabilities may need to be established. The estimate treats both situations honestly instead of assuming spare capacity is free.

The alternative may be a vendor-hosted arrangement with a simpler operating responsibility, subject to its data path and feature fit. We compare the options using your actual constraints. We do not present self-hosting as inherently secure or vendor hosting as inherently unsuitable. Configuration, access, dependencies and recovery determine what the finished system can support.

We also distinguish a business requirement from an assumption about regulation or a customer contract. If the permitted processing, storage or support locations are not yet clear, that remains an unresolved input for the appropriate owner or adviser. The architecture should respond to an established requirement rather than manufacture a compliance conclusion.

Accept the operating evidence, not only the installation

A hosting handover should demonstrate the application, its connected workflows and the operating procedures named in the scope. We inspect representative outputs, alerts, access roles and the restore evidence. The operator should know where configuration lives and how an approved change reaches the running environment.

The data-path record identifies what is known and what still depends on a provider setting or contractual confirmation. It is versioned alongside material changes to the architecture. Adding a model provider or moving backups later can change the path even when the application host stays in the same Australian region.

We test the alert route without creating a real business incident. The person receiving it should be able to identify whether the affected layer is the host, a connection or a workflow, and find the relevant recovery notes. Monitoring that reaches an unattended inbox is an incomplete operational handover.

Finally, we confirm who continues each responsibility after acceptance. If your team operates the host while we maintain workflows, both sides need a shared escalation boundary. If a scoped care engagement covers more of the stack, its responsibilities are written down. Your ownership remains intact, and the system should be transferable to another capable operator with the appropriate access and documentation.

Name the operator for each layer

A self-hosted system has several layers of responsibility. The infrastructure provider supplies the agreed hosting service. Someone still needs to configure and maintain the operating environment, n8n, the database, credentials and the workflows. A cloud-provider status page does not cover every one of those layers.

We put the owner beside each responsibility and confirm the access needed to perform it. Who receives a storage alert? Who can restore a database? Who approves an upgrade? Who can rotate a credential when the original administrator is unavailable? A practical answer includes a route to the account, not just a person’s name in a diagram.

The care scope defines which responsibilities we take on and which remain with your team or another supplier. Response and recovery commitments depend on that arrangement and the infrastructure selected. We do not infer round-the-clock incident coverage from a monthly support fee or publish a service guarantee that has not been agreed.

A backup needs a demonstrated route back

A backup is useful only when the required system can be restored from it. We identify the database, workflow configuration, credential encryption material and any external files required by the design. The restore procedure records where those pieces live and which authorised operator can retrieve them.

n8n documents that it encrypts stored credentials using an encryption key created at first launch or configured by the operator. Its queue-mode guidance requires the configured key across workers. That makes key custody part of recovery planning. Restoring a database without the matching required key is not an adequate demonstration that the credentialed system can resume.

The restore test happens in an appropriately isolated environment. Outbound production actions remain disabled until the restored state has been checked. We reconcile the point in time of the backup with records already written after that point, then decide which pending items may safely continue. Restoration of a server and restoration of correct business behaviour are related but separate acceptance checks.

Choose security settings against the actual edition

n8n’s security documentation describes controls covering secure connections, user access, the public API, node availability and execution data. We use those as configuration questions for the proposed deployment. We still check availability and behaviour against the selected edition and current version before promising a control in your scope.

The review starts with who can enter the editor and what they can reach from a workflow. An administrator with broad tool access may be able to send data to a new destination even when the application server itself is in an approved region. We consider the network, node and account boundaries together, rather than treating the login page as the whole security model.

Logs and execution history need their own access and retention decisions. Capturing a full document in every run can expand the amount of sensitive material stored beyond what an operator needs to diagnose a failure. We decide which evidence is necessary, what should be redacted or excluded and how a recovery case remains understandable after that reduction.

Account for platform communication as well as your workflows

The outbound review includes communication by the platform itself. n8n documents that self-hosted installations collect telemetry by default and provides an opt-out configuration. That is a setting to review deliberately, alongside version checks and any other service required by the chosen edition.

Current n8n pricing documentation says self-hosted Business and Enterprise licences require a daily licence-server ping that includes production execution usage. We include that requirement when assessing the proposed network boundary. Turning off optional diagnostic telemetry does not remove a paid licence obligation. If the requirement is complete network isolation, the chosen edition and commercial arrangement need explicit confirmation before implementation.

Disabling diagnostic telemetry should not be confused with proving that nothing can leave the host. A workflow may still call an external CRM or model provider, and paid-edition licensing has its own operating requirements. We document the proposed configuration and verify the relevant provider terms instead of making an isolation promise based on one environment variable.

The same discipline applies to support. An operator may view execution records, download a diagnostic file or use a remote support tool. The access model and permitted handling of those records need agreement. If your requirement constrains who can access information or where processing can occur, those requirements belong in the acceptance criteria before implementation begins.

Keep an upgrade from becoming an unplanned migration

We record the working version, dependencies and configuration, then agree how an update is evaluated. Representative workflows should run against a safe environment with their ordinary, empty and exception inputs. A release is not ready simply because the editor loads successfully.

The change plan includes a backup, the compatibility decisions that matter and a procedure for returning to the previous working state if needed. Changes to stored data or credentials can make rollback more involved than selecting an older container. We assess the proposed release before relying on a simple version reversal.

Capacity is reviewed with the actual workload. A busy document workflow and many small record updates place different demands on execution time, storage and dependencies. We test the agreed concurrency and failure behaviour, then document the limit that should trigger review. Adding workers or a queue without an operating reason would increase the recovery burden without establishing that the business needs it.