How to Host n8n on Fly.io: Step-by-Step Guide for Australian Deployments

Updated February 2026. This article has been reviewed and updated to reflect the latest information.

If you’re an Australian business looking to self-host n8n on infrastructure that’s close to home, Fly.io is well worth a look. We’ve deployed n8n on Fly.io for a number of our Australian clients at Osher Digital, and it runs well from the Sydney region without much configuration fuss.

This guide walks you through the whole process, from installing the Fly CLI to running a production-ready n8n instance with persistent storage, PostgreSQL, custom domains, and SSL. If you’re weighing up your self-hosting options more broadly, our complete guide to self-hosting n8n covers the alternatives, and our Docker-based n8n hosting guide is worth reading if you’re leaning towards containers.

For tailored advice on which hosting approach suits your business, our n8n consulting team can help you decide.

Why Fly.io Works Well for n8n

Fly.io runs your Docker containers on lightweight Firecracker micro-VMs across a global edge network. For Australian deployments, a few things stand out:

• Sydney region (syd): Fly.io operates a data centre in Sydney, which means sub-10ms latency for east-coast Australian users and compliance with data residency requirements.
• Edge deployment model: Your app runs on bare-metal servers rather than nested virtualisation, so you get better performance per dollar.
• Pay-for-what-you-use pricing: There’s a free allowance that can cover small n8n deployments entirely.
• Batteries included: Private networking, persistent volumes, managed Postgres, TLS termination, and zero-downtime deploys are all built in.
• Simple CLI workflow: Deploying and managing apps feels closer to Heroku than to managing raw VMs.

If your business handles sensitive data (healthcare, finance, government), the Sydney region means your workflow data and credentials stay in Australia.

Prerequisites

Before you begin, make sure you have:

1. A Fly.io account. Sign up at fly.io. You’ll need a credit card on file even for the free tier.
2. The Fly CLI (flyctl) installed. Install it with:

# macOS
brew install flyctl
# Linux
curl -L https://fly.io/install.sh | sh
# Windows
powershell -Command "iwr https://fly.io/install.ps1 -useb | iex"

1. Authenticated CLI session:

fly auth login

1. Basic familiarity with the terminal and Docker concepts (though you won’t need Docker installed locally).

Step 1: Create the Fly.io App

Start by creating a new Fly.io application. We’ll explicitly set the region to Sydney:

fly apps create n8n-your-company --region syd

Replace n8n-your-company with your preferred app name. This must be globally unique across Fly.io.

Step 2: Configure fly.toml

Create a fly.toml file in your project directory. This is the core configuration file for your Fly.io deployment:

app = "n8n-your-company"
primary_region = "syd"
[build]
  image = "n8nio/n8n:latest"
[env]
  N8N_HOST = "n8n-your-company.fly.dev"
  N8N_PORT = "5678"
  N8N_PROTOCOL = "https"
  WEBHOOK_URL = "https://n8n-your-company.fly.dev/"
  GENERIC_TIMEZONE = "Australia/Brisbane"
  N8N_DEFAULT_LOCALE = "en"
  DB_TYPE = "postgresdb"
  EXECUTIONS_DATA_PRUNE = "true"
  EXECUTIONS_DATA_MAX_AGE = "168"
[http_service]
  internal_port = 5678
  force_https = true
  auto_stop_machines = "stop"
  auto_start_machines = true
  min_machines_running = 1
  [http_service.concurrency]
    type = "requests"
    hard_limit = 250
    soft_limit = 200
[[vm]]
  size = "shared-cpu-1x"
  memory = "512mb"
[mounts]
  source = "n8n_data"
  destination = "/home/node/.n8n"
[checks]
  [checks.health]
    type = "http"
    port = 5678
    path = "/healthz"
    interval = "30s"
    timeout = "5s"
    grace_period = "15s"

A few things to note here:

• auto_stop_machines is set to "stop", which means Fly.io will stop your machine when it’s idle and restart it on the next request. Set this to "off" if you need always-on availability (for example, if you rely on n8n’s built-in cron triggers).
• min_machines_running = 1 ensures at least one instance is always warm.
• The health check hits n8n’s built-in /healthz endpoint to confirm the service is responsive.

Step 3: Set Up Persistent Storage with Fly Volumes

n8n stores encryption keys, credentials, and local file data in its working directory. You need a persistent volume so this data survives deployments and restarts:

fly volumes create n8n_data --region syd --size 1

This creates a 1 GB volume in the Sydney region. For most n8n deployments, 1 GB is ample. You can extend it later without downtime:

fly volumes extend <volume-id> --size 5

Important: Fly Volumes are tied to a specific region and physical host. They are not replicated. We’ll cover backup strategies later in this guide.

Step 4: Set Up PostgreSQL on Fly.io

n8n can run on SQLite, but PostgreSQL is a much better fit for production. It handles concurrent executions more reliably and you’ll need it if you ever want to scale.

Create a Fly Postgres cluster:

fly postgres create --name n8n-db --region syd --initial-cluster-size 1 --vm-size shared-cpu-1x --volume-size 1

Once the database is provisioned, attach it to your n8n app:

fly postgres attach n8n-db --app n8n-your-company

This automatically sets the DATABASE_URL secret on your n8n app. However, n8n expects individual database connection variables, so you’ll need to set those manually.

Step 5: Configure Environment Variables and Secrets

Set your database connection details and n8n encryption key as Fly secrets. Fly encrypts these and injects them at runtime:

fly secrets set \
  DB_POSTGRESDB_HOST="n8n-db.flycast" \
  DB_POSTGRESDB_PORT="5432" \
  DB_POSTGRESDB_DATABASE="n8n" \
  DB_POSTGRESDB_USER="n8n" \
  DB_POSTGRESDB_PASSWORD="your-secure-password" \
  N8N_ENCRYPTION_KEY="your-random-encryption-key" \
  N8N_BASIC_AUTH_USER="admin" \
  N8N_BASIC_AUTH_PASSWORD="your-admin-password" \
  --app n8n-your-company

Generate a strong encryption key with:

openssl rand -hex 32

Critical: Store your N8N_ENCRYPTION_KEY somewhere safe outside of Fly.io. If you lose it, all your stored credentials become unrecoverable. We recommend a password manager or a secrets vault.

Step 6: Deploy n8n to Fly.io

Now deploy:

fly deploy --app n8n-your-company

Fly.io pulls the n8n Docker image, provisions your machine in Sydney, attaches the volume, and starts the service. The first deploy usually takes 60-90 seconds.

Monitor the deployment:

fly logs --app n8n-your-company

Once you see n8n’s startup message confirming it’s listening on port 5678, your instance is live at https://n8n-your-company.fly.dev.

Step 7: Custom Domain and SSL Setup

You’ll probably want your own domain for production. Fly.io handles TLS certificates automatically via Let’s Encrypt:

fly certs create n8n.yourdomain.com.au --app n8n-your-company

Then add a CNAME record with your DNS provider:

n8n.yourdomain.com.au  CNAME  n8n-your-company.fly.dev

Fly.io will provision and renew the TLS certificate automatically. Update your fly.toml environment variables to reflect the new domain:

fly secrets set \
  N8N_HOST="n8n.yourdomain.com.au" \
  WEBHOOK_URL="https://n8n.yourdomain.com.au/" \
  --app n8n-your-company

Scaling Considerations

For small to medium workloads (under 10,000 executions per day), a single shared-cpu-1x machine with 512 MB RAM is usually enough. As your usage grows, consider:

• Vertical scaling: Upgrade to shared-cpu-2x with 1 GB RAM, or move to performance-1x for dedicated CPU.
• Queue mode: For high-throughput deployments, n8n supports a queue mode with separate main and worker instances. This requires Redis and a more involved configuration, but it allows horizontal scaling.
• Always-on machines: If you’re running time-sensitive cron workflows, set auto_stop_machines = "off" to prevent cold starts.

Resize your VM without redeploying:

fly scale vm shared-cpu-2x --memory 1024 --app n8n-your-company

Monitoring and Health Checks

The health check in fly.toml automatically restarts unhealthy instances. For more visibility:

# Check machine status
fly status --app n8n-your-company
# View recent logs
fly logs --app n8n-your-company
# SSH into the running machine for debugging
fly ssh console --app n8n-your-company

For production, it’s worth setting up an external uptime monitor (Uptime Robot or Better Uptime work well) to ping your n8n health endpoint every few minutes.

Cost Breakdown in AUD

Fly.io’s pricing is usage-based. Here’s what you can expect for an n8n deployment in the Sydney region (approximate AUD values as of early 2026):

For a typical small business n8n deployment, expect to pay around $15-25 AUD per month. That’s cheaper than n8n Cloud’s paid plans and you get full control over your data and configuration.

Data Sovereignty and the Sydney Region

If your organisation is subject to the Privacy Act 1988, the Australian Privacy Principles (APPs), or industry-specific regulations like APRA CPS 234, hosting n8n in Fly.io’s Sydney region keeps things simple:

• Workflow execution data stays in Australia.
• Stored credentials and API keys remain on Australian infrastructure.
• You can show data residency compliance to auditors without jumping through hoops.

That matters when the alternative platforms only offer US or European hosting regions.

Updating n8n on Fly.io

To update to the latest n8n version, just redeploy:

fly deploy --app n8n-your-company

Since fly.toml references n8nio/n8n:latest, this pulls the newest image. For more control, pin to a specific version:

[build]
  image = "n8nio/n8n:1.75.2"

We recommend testing updates in a staging environment first, particularly for major version bumps. Check the n8n release notes before upgrading.

Backup Strategies for Fly Volumes

Fly Volumes are not backed up or replicated automatically. For production, you should have at least one of these in place:

1. Snapshot-based backups (built-in):

# Create a snapshot
fly volumes snapshots create <volume-id> --app n8n-your-company
# List snapshots
fly volumes snapshots list <volume-id> --app n8n-your-company

2. Database backups via pg_dump:

# SSH into the Postgres app and dump the database
fly ssh console --app n8n-db -C "pg_dump -U postgres n8n" > n8n-backup-$(date +%Y%m%d).sql

3. Automated backup script:

Set up a cron job (or an n8n workflow, fittingly) to run daily database dumps and upload them to an S3-compatible bucket like AWS S3 Sydney or Cloudflare R2.

At minimum, back up your PostgreSQL database daily and your encryption key once (stored securely offline).

Troubleshooting Common Fly.io Deployment Issues

Machine won’t start / OOM errors: If n8n runs out of memory during complex workflow executions, scale up your VM:

fly scale vm shared-cpu-1x --memory 1024 --app n8n-your-company

Volume not mounting: Ensure the volume name in fly.toml matches the volume you created. Volumes are region-specific, so if your machine gets scheduled in a different region, it won’t find the volume:

fly volumes list --app n8n-your-company

Database connection refused: Verify the Postgres app is running and the flycast DNS name resolves correctly:

fly status --app n8n-db
fly ssh console --app n8n-your-company -C "nslookup n8n-db.flycast"

Webhooks not triggering: Ensure WEBHOOK_URL matches your public URL exactly (including the trailing slash). If you’re using auto_stop_machines, your machine may need a moment to wake before processing the webhook. Fly.io handles this automatically, but there can be a brief cold-start delay.

502 errors after deploy: n8n can take 10-15 seconds to fully start up, especially on first boot with database migrations. The grace_period in the health check configuration gives it breathing room before Fly.io starts routing traffic to it.

TLS certificate not provisioning: Double-check your DNS CNAME record is pointing to the correct Fly.io hostname and has propagated. You can verify with:

fly certs show n8n.yourdomain.com.au --app n8n-your-company

Need Help With Your n8n Deployment?

If you’d rather not deal with the infrastructure side, our team at Osher Digital handles n8n deployments for Australian businesses, covering setup, ongoing maintenance, and workflow development. We work with Fly.io, Docker, Railway, and other hosting platforms depending on what fits.

Get in touch if you want to chat about your project, or book a call with our n8n consulting team.

Frequently Asked Questions

Is Fly.io’s free tier sufficient for running n8n in production?

For very light workloads (a handful of workflows running a few times a day), the free tier can work. But we’d recommend the shared tier at around $15-25 AUD/month for anything you’re relying on. The free tier has limits on volume storage and machine uptime that tend to cause reliability problems once you’re using it properly.

How does Fly.io compare to Railway or Render for hosting n8n?

The big differentiator for Australian deployments is Fly.io’s Sydney region, which neither Railway nor Render currently offer. Fly.io also gives you more control over machine sizing, volumes, and networking. Railway is simpler to get going but routes traffic through US regions, which adds 150-200ms of latency for Australian users. For a broader comparison, see our self-hosting n8n guide.

Can I run n8n on Fly.io with SQLite instead of PostgreSQL?

Yes. Remove the PostgreSQL-related environment variables and make sure your Fly Volume is properly mounted. SQLite stores everything in a single file on the volume. The catch is that SQLite doesn’t handle concurrent writes well, so if you’re running multiple workflows at once or expect to grow, PostgreSQL is the better option.

What happens to my data if Fly.io experiences an outage in the Sydney region?

Fly Volumes sit on NVMe drives attached to the physical server hosting your machine. If the server goes down, your data is preserved once it comes back, but your n8n instance will be unavailable in the meantime. You can run multiple machines across regions for higher availability, but n8n’s architecture makes true multi-region setups complex. The practical approach is regular backups to external storage (as outlined above) plus a documented recovery procedure.

How do I migrate an existing n8n instance to Fly.io?

Export your workflows from your existing n8n instance (Settings > Export), set up the Fly.io deployment as described in this guide, then import your workflows into the new instance. For credentials, you’ll need to re-enter them manually in the new instance since they’re encrypted with the original instance’s encryption key. If you’re migrating from another Docker-based host and have access to the original encryption key, you can set the same key in Fly.io to preserve credential encryption.

Does Fly.io support n8n’s queue mode for scaling workers?

Yes. You can deploy separate Fly.io apps for the n8n main process and worker processes, sharing a PostgreSQL database and a Redis instance. Fly.io offers managed Redis through Upstash integration. It takes more work to set up, but it lets you scale workflow execution capacity independently. If you want a hand with this, book a call with our team.