Skip to content
n8n Workflow Automation product logo
  • AWS· soonComing soon on Amazon Web Services
  • Azure· soonComing soon on Microsoft Azure
  • GCP· nextGoogle Cloud is next on the roadmap
Coming soon

n8n Workflow Automation

n8n 2.38.7 on Node.js 24 with PostgreSQL 16, behind an Apache reverse proxy with websocket support - self-hosted workflow automation with your credentials encrypted under a key that exists only on your instance. No account ships: you become the owner on the first visit, and webhooks keep working after a stop/start.

Version
v2.38.7
Operating system
Ubuntu 24.04 LTS
Architecture
x86_64
Support
Community

What's installed

Every package and version on the image, identical on every cloud it ships on. Nothing else is installed.

  • n8n 2.38.7
  • Node.js 24.21.0
  • PostgreSQL 16.15
  • Apache 2.4.58

LicensingSustainable Use License (fair-code), no licence key required

Deploy anywhere

n8n Workflow Automation on AWS and Azure.

Google Cloud is next on the roadmap. One clean-room build, one first-boot credential model, one patch cadence — identical on every cloud you run. Every identifier below is the real one; copy it and launch.

  1. AWS
    Coming soon

    Amazon Web Services

    AMI · v2.38.7

    AWS AMI ID
    ami-09d90f081408ddc98
    Released
    Root volume
    gp3 · 20 GiB
    Instance types
    • t3a.medium
    • t3.medium
    • t3a.large
    • m6a.large
    Regions
    • us-east-1
    AWS launch steps
  2. Azure
    Coming soon

    Microsoft Azure

    Compute Gallery image · v2.40.6

    Azure Compute Gallery image ID
    …/galleries/provencloud/images/n8n/versions/2026.9.1
    Released
    OS disk
    Premium_LRS · 30 GiB
    Gallery
    provencloud
    Definition
    n8n
    Resource group
    provencloud-images-rg
    VM sizes
    • Standard_D2as_v7
    • Standard_B2ms
    • Standard_D4as_v7
    • Standard_D2as_v5
    Regions
    • eastus
    Azure launch steps
AWS

Getting started on Amazon Web Services

From launch to signed in, step by step.

  1. Launch in us-east-1 with TCP 22 and 80 open; wait about two minutes.

  2. Open http://<instance-public-ip>/. n8n shows its owner-setup screen on the first visit: choose your email and password there. No default credential exists.

  3. Webhook and editor URLs are pinned to the instance's public IP on every boot. Set N8N_HOST to your own hostname in /etc/n8n/n8n.env and it is never overwritten.

  4. SSH as ubuntu with your key pair. Config: /etc/n8n/n8n.env (root-only). Data: /var/lib/n8n. Logs: /var/log/n8n. Backup: sudo bash /home/ubuntu/iscripts/n8n-backup.sh writes a pg_dump archive to /var/backups/n8n.

  5. For production put TLS in front and set N8N_SECURE_COOKIE=true.

Security posture

What this AWS image does and does not ship with, one fact per line.

  • Clean-room build on Canonical's official Ubuntu 24.04 LTS image: every component comes from its own official repository or release, nothing is copied from any third-party image, and the finished image was scanned for third-party vendor strings before capture.

  • No usable credential ships in the image; passwords are set on your instance at first boot from EC2 instance metadata (IMDSv2) and the scripts that set them delete themselves afterwards.

  • SSH is key-only, root login over SSH is refused, and build-time SSH keys, shell history and logs were removed before imaging.

  • N8N_ENCRYPTION_KEY, which encrypts every stored credential, is generated on first boot once, while no credentials exist - a key baked into the image would let anyone holding it decrypt any other customer's credentials.

  • The config file holding the database password and encryption key is root:n8n mode 0640 and not readable by the ubuntu login user. n8n (5678) and PostgreSQL (5432) are loopback-only.

  • N8N_SECURE_COOKIE is false so sign-in works over plain HTTP at a bare IP; set it to true once TLS is in front.

  • The build key pair is denied for both ubuntu and root, and authorized_keys contain only the launching instance's own key.

  • Fifteen automated checks pass on build, first boot and after a stop/start.

  • The image is HTTP-only by design so it works at a bare IP with no certificate warnings: terminate TLS at a load balancer or add a certificate before exposing it publicly, and restrict port 22 and any admin ports to trusted IP ranges in your security group.

Azure

Getting started on Microsoft Azure

From launch to signed in, step by step.

  1. Deploy the gallery image in eastus with TCP 22 and 80 open in your network security group - this image needs no other ports. Choose ubuntu as the administrator username so SSH and the script paths match. Wait about three minutes for first boot.

  2. Open http://<vm-public-ip>/. No account ships with this image - n8n shows its owner-setup screen and the first person to complete it becomes the owner, so do this promptly after the VM boots.

  3. There is no password to look up for n8n itself. SSH as ubuntu with your key; the PostgreSQL database is on loopback only.

Security posture

What this Azure image does and does not ship with, one fact per line.

  • Clean-room build on Canonical's official Ubuntu image from the Azure Marketplace: every component comes from its own official source and no third-party image was launched or copied.

  • No n8n account ships at all - the first visitor completes the owner-setup screen.

  • The per-instance n8n encryption key is generated on first boot, so workflow credentials encrypted on one VM cannot be read on another.

  • The pre-image cleanup proves the build's own credentials are rejected before capture, and first boot sets every password from the new VM's own vmId, read from Azure IMDS.

  • The ubuntu login account ships password-locked with an empty authorized_keys, and cloud-init installs your own SSH key at deploy time.

  • Shell history, logs and cloud-init state are cleared before capture.

  • Verified against Microsoft's documented Linux certification test cases on a VM deployed from this gallery version - 13 passed, 0 failures - with VM extension provisioning confirmed and every helper script executed rather than only reviewed.

  • The database listens on loopback only and is never exposed.

  • Restrict port 22 to trusted IP ranges, and put the consoles behind HTTPS with your own certificate before exposing them to the internet.