n8n Hosting Options for Docker, Kubernetes, and AWS

What n8n-hosting contains

n8n-hosting is a collection of deployment examples for n8n, which the README identifies as a workflow automation platform. It is aimed at operators who need to decide where and how to run n8n, rather than developers looking for workflow implementation code. The repository covers several hosting models because their operational needs differ. Docker Compose examples cover a single service with PostgreSQL, a queue-mode deployment with workers and Redis, a subfolder deployment behind an SSL reverse proxy, and Caddy-based proxying.

For Kubernetes users, the repository includes an official n8n Helm chart intended for production deployments. It also retains raw Kubernetes manifest examples associated with cloud provider tutorials for AWS, Azure, and GCP. The AWS section goes further, providing an ECS Fargate example with multi-main queue mode, RDS PostgreSQL, ElastiCache Redis, S3 binary storage, HTTPS through an Application Load Balancer, and worker autoscaling.

This scope makes the repository useful as a deployment catalog, but it also creates a selection problem. None of those paths should be treated as interchangeable. A Docker Compose file can suit a small deployment, while the ECS example assumes several managed AWS services and queue-mode components. Users should select the environment first, then inspect the files for that environment.

Database and queue-mode choices

The most consequential configuration choice is the database. The README recommends PostgreSQL 17 or 18 for production, lists PostgreSQL 16 for compatibility, and says the templates deploy version 18. It also advises using the latest minor within the chosen major. This is a concrete platform baseline, but n8n does not publish a version-by-version support matrix. Its stated policy is to support actively maintained dependency releases, so the repository directs users to the linked n8n documentation for the release being deployed.

SQLite is bundled and is the default when queue mode is off. The README describes it as suitable for development and small single-instance setups. MySQL and MariaDB are not supported as the n8n backend: they were deprecated in n8n v1.0 and removed in v2.0. That removal applies to the backend database, not the n8n MySQL node, which remains a separate product feature.

Queue mode adds a different dependency. Redis 7 or newer is recommended, and Redis 6 or newer is required when a Redis username is configured. Valkey is described as a Redis-compatible drop-in for queue mode, but n8n does not separately guarantee its version policy. Amazon Aurora PostgreSQL is also PostgreSQL-compatible, yet the HA CloudFormation template labels it experimental. n8n neither tests nor certifies it, so compatibility cannot be inferred merely from its PostgreSQL interface.

Installing the Kubernetes Helm chart

The README gives a direct Helm installation command for the official n8n chart. The `-f` argument supplies a local values file, so the reader must create and review that file before executing the command. The repository also directs users to the chart README and its examples directory for the full configuration surface.

The documented installation command is:

helm install n8n oci://ghcr.io/n8n-io/n8n-helm-chart/n8n -f my-values.yaml

This is the first real deployment step because it installs an `n8n` release from an OCI-hosted chart and applies `my-values.yaml`. The README does not document the contents of a minimal values file or the command for a first subsequent upgrade, so this repository overview should not invent either. Those details need to come from `charts/n8n/README.md` and the selected example files.

The README recommends pinning a specific n8n image tag for production instead of relying on `stable` or `latest`. Pinning matters because this hosting repository is a set of examples, not a version selection service. Operators still need to determine the n8n release they intend to deploy and confirm its dependencies against the linked n8n documentation.

Choosing a Docker Compose deployment

The Docker Compose directory provides four documented starting points. `docker-compose/withPostgres/` is the basic n8n and PostgreSQL arrangement. `docker-compose/withPostgresAndWorker/` adds PostgreSQL, Redis, and a worker, which corresponds to queue mode. `docker-compose/subfolderWithSSL/` places n8n behind an SSL reverse proxy when the application is served from a subfolder. The `docker-caddy/` directory provides another reverse-proxy option using Caddy.

The README does not provide a single repository-level `docker compose up` command, environment-variable list, port mapping, or default credentials for these examples. Consequently, there is no verified command to reproduce here. A first user should open the desired directory, inspect its Compose file and any included configuration, then follow the commands documented beside those files. The top-level README lists the directory names and brief descriptions.

These examples are not all trying to solve the same problem. The PostgreSQL-only example is the closest to a conventional single-instance setup. The worker example is relevant when processing must be separated through queue mode. The proxy examples address network placement and TLS termination, not database scaling. Picking the closest directory by name without checking persistence, volumes, environment variables, and proxy routing would leave important deployment behavior unverified.

AWS ECS and raw Kubernetes scope

The AWS CloudFormation example is materially broader than the Docker Compose examples. According to the README, it configures n8n on ECS Fargate with multi-main queue mode. It combines RDS PostgreSQL, ElastiCache Redis, S3 binary storage, an Application Load Balancer for HTTPS, and worker autoscaling. The presence of all of these components indicates a distributed deployment model rather than a local convenience stack.

That additional scope also raises the adoption threshold. This example is relevant to teams already deploying into AWS and willing to manage the networking, data services, object storage, HTTPS endpoint, and worker capacity described by the template. The README does not claim that the template covers backups, monitoring, disaster recovery, or zero-downtime upgrades. Those responsibilities cannot be added to the template's advertised feature list without inspecting the actual CloudFormation files and supporting documentation.

The `kubernetes/` directory has a different purpose again. The README says it contains raw manifest examples used in cloud provider tutorials for AWS, Azure, and GCP. Raw manifests can be easier to inspect than generated Helm output, but they also place responsibility on the operator for maintaining and updating every resource. The Helm chart offers a documented chart interface and examples, whereas raw manifests are presented as tutorial material. The repository does not state that both paths provide identical production capabilities.

Maintenance, upgrades, and MIT licensing

The repository is not archived, and its last push was on 2026-10-16. Recent tagged releases include v1.16.0 on 2026-10-14, v1.15.0 on 2026-10-07, and v1.14.0 on 2026-09-30. These dates indicate recent repository activity, but the README does not publish a compatibility statement for every hosting file or chart change. Users should consult `CHANGELOG.md` when determining what changed between versions.

Upgrade cost depends on the deployment model. A pinned single-instance deployment still needs attention to n8n, PostgreSQL, persistence, credentials, and configuration compatibility. Queue mode adds worker and Redis coordination. ECS Fargate adds managed infrastructure and worker autoscaling, while Kubernetes adds manifests or Helm values that must remain aligned with the target cluster. The repository provides examples for these paths, but the top-level README does not define rollback, backup, restore, or migration procedures.

The repository uses the MIT License and points to `LICENSE.md`. That identifies the licensing terms for this hosting repository. It does not, by itself, establish the license or separate commercial terms of n8n, third-party images, cloud services, or other components used by a deployment.

Editorial conclusion

Adopt this repository when you need an official, n8n-specific starting point for container or Kubernetes deployment, and prefer PostgreSQL with a pinned n8n image for production. Do not treat the examples as a complete operations manual or use Aurora without checking its experimental status. Before deployment, verify the selected n8n release against its official documentation, pin the image version, and review the exact configuration for persistence, queue workers, storage, TLS, backups, and upgrades.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. n8n-io/n8n-hosting on GitHub
4. README
5. Releases