n8n automation AMI for AWS: self-hosted workflows live in minutes, not hours

n8n's appeal is straightforward: own the automation layer instead of renting it from a SaaS vendor that caps monthly executions or gates integrations behind pricing tiers. The catch is that self-hosting n8n properly means more than installing the application. It means wiring up Node.js, putting a real database behind it instead of the default SQLite (which doesn't hold up under production workloads), and making sure the service survives a reboot without manual intervention. All of that has to happen before the first workflow gets built.

This AMI removes that setup work. It's a complete n8n environment on Ubuntu 26.04, backed by PostgreSQL 18 and managed as a systemd service, built to go from "instance launched" to "workflow running" in minutes rather than hours.

Quick facts

Table 1. At-a-glance specification of the n8n Automation AMI.

Why self-host n8n instead of the cloud version

Self-hosting removes per-execution and per-workflow pricing tiers entirely. Compute is the only constraint, not a usage ceiling. It also keeps full control over data flowing through connected integrations, which matters the moment a workflow touches customer data or internal systems that shouldn't pass through a third-party SaaS backend. And it comes with unrestricted access to n8n's full integration library and custom node support, without platform-imposed limits on what can be connected or how.

Architecture: what's running under the hood

Table 2. Core components bundled into this AMI.

The database choice is the detail most DIY setups get wrong: n8n defaults to SQLite, which is fine for evaluation but becomes a liability under concurrent executions and larger workflow histories. Shipping with PostgreSQL preconfigured from the start avoids a painful database migration later.

What you can actually build with it

Table 3. Representative workflow types n8n's canvas supports out of the box.

Self-hosted n8n vs. the alternatives

Table 4. How self-hosting compares against n8n Cloud and mainstream SaaS automation tools.

From launch to first workflow

Once the instance is running, n8n is reachable immediately on the instance's public IP over port 5678. The first visit walks through creating the administrator account, and from there it's straight into the workflow editor. There's no separate setup phase between the server coming online and the team being able to use it.

Security hardening checklist

Table 5. Baseline hardening steps to apply after first launch.

Backup and scaling considerations

Because workflow definitions, credentials, and execution history all live in PostgreSQL, a standard pg_dump (or EBS snapshot of the data volume) on a schedule is sufficient for disaster recovery. There's no separate datastore to coordinate. As execution volume grows, the first scaling lever is usually instance size (moving from t3.medium toward the m5 or c6i families). Past that, n8n supports a queue-mode architecture that separates the editor/API from worker processes, which is the standard next step for high-throughput production use.

Common pitfalls to avoid

Table 6. Mistakes most commonly made in early n8n deployments.

How billing works

Pricing is usage-based at $0.10 per hour, in addition to normal AWS EC2 infrastructure costs for the chosen instance size. There's no end date on the subscription, and it can be canceled at any time.