DEV Community

Cover image for Self-hosting n8n for production AI automations without babysitting a server
Amit Shukla
Amit Shukla

Posted on Originally published at amitshuklabag.hashnode.dev

Self-hosting n8n for production AI automations without babysitting a server

#n8n #ai #automation #selfhosted

You built an n8n workflow that matters. Maybe it is an AI agent that answers customers on Telegram, a pipeline that summarizes every support ticket with Claude, or an automation that turns new leads into enriched CRM records. It works beautifully on your laptop.

Then someone asks the obvious question: "Can we turn it on for real?"

That is the moment n8n stops being a tool and becomes a service. Services have to be up at 3 AM, reachable from the internet, backed up, patched and watched. This article walks through what production n8n actually needs, then shows the fastest way to get all of it running without turning one engineer into a part time sysadmin.

Why AI automations raise the bar

A classic n8n workflow that copies rows between two apps once an hour is forgiving. If it misses a run, it catches up. AI workflows are different in three ways.

They are triggered from outside. A Telegram bot, a Slack app, a form or a payment provider calls your n8n through a webhook. That means n8n needs a public HTTPS address that is always reachable. Telegram, for example, only delivers updates to HTTPS endpoints.

They hold valuable credentials. Your Anthropic or OpenAI key, your CRM token, your database password. n8n encrypts stored credentials with an encryption key, and anyone with the database and that key can use every one of them.

They are user facing. When an AI agent answers customers, a five minute outage is a customer waiting for a reply that never comes.

So production n8n is less about n8n and more about everything around it.

What production n8n actually needs

A public domain with HTTPS that renews itself

Webhooks need a stable HTTPS URL, and n8n needs to know that URL so it can register webhooks correctly. You set it with the WEBHOOK_URL environment variable:

WEBHOOK_URL=https://n8n.yourcompany.com/
Enter fullscreen mode Exit fullscreen mode

Behind that you need a reverse proxy, a certificate, and automatic renewal. An expired certificate silently breaks every webhook at once.

Postgres instead of SQLite

Out of the box n8n stores everything in SQLite, which is perfect on a laptop. For production, the n8n docs recommend Postgres, so the database can handle concurrent executions and be backed up and restored properly:

DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n
DB_POSTGRESDB_PASSWORD=<strong password>
Enter fullscreen mode Exit fullscreen mode

A safe encryption key

n8n generates an encryption key the first time it starts and uses it to encrypt every stored credential. Set it explicitly so it never changes between deployments:

N8N_ENCRYPTION_KEY=<long random value, stored somewhere safe>
Enter fullscreen mode Exit fullscreen mode

If you lose this key, every saved credential becomes unreadable. If it leaks along with your database, every credential is exposed. It needs to be backed up, but separately and carefully.

Execution data that doesn't fill the disk

Every execution stores its input and output data. AI workflows pass large payloads around, full documents, long model responses, so the database grows fast. Turn on pruning:

EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168
Enter fullscreen mode Exit fullscreen mode

That keeps a week of history, enough to debug, without letting the disk quietly fill up.

Backups you have actually restored

Back up the Postgres database on a schedule, keep copies off the server, and keep the encryption key with them. Then do the part most teams skip: restore a backup onto a fresh instance and check that your workflows and credentials come back. A backup you have never restored is a hope, not a backup.

Updates without surprises

n8n ships updates frequently, with new nodes, AI features and security fixes. Staying current matters, especially for an internet facing service. Each update should be a planned step with a database backup right before it and a way back if something breaks.

Monitoring that tells you first

You want to know when the instance is down, when the disk is close to full, when memory spikes and when executions start failing, before a customer tells you. That means health checks, metrics, alerts and someone who receives them.

Security in front of the server

A firewall that only exposes what's needed, protection against floods of traffic, and OS security patches applied on time. An automation server with your AI keys and CRM credentials is exactly the kind of target worth protecting properly.

The real cost: someone has to own all of it

None of the items above is hard on its own. Together, they are an ongoing job: certificates, Postgres, backups, restore tests, updates, pruning, monitoring, firewall rules, OS patches. And it doesn't end, because n8n, Postgres and the operating system all keep releasing updates.

In most teams this lands on whoever set n8n up first. It works until that person is on holiday during an incident, or the one undocumented step gets skipped during an upgrade.

The goal is to keep the parts you care about, your workflows, your agents, your data, and hand off everything else.

The fastest path: fully managed n8n on Elestio

Elestio runs exactly that layer. You pick n8n from a catalog of 400+ open source templates, choose where it runs, a major cloud provider and region of your choice, and it deploys onto a dedicated instance that is yours.

From there, the production checklist above is already handled:

  • HTTPS out of the box, with certificates that issue and renew on their own, so webhooks for Telegram, Slack and every other trigger just work
  • Automated encrypted backups, stored off host, with retention and restores you can run
  • Automatic OS patching and application updates, so you stay on current, secure n8n versions with a way back
  • Monitoring and alerting on the instance, so problems reach you first
  • A firewall and DDoS protection in front of the instance
  • Managed SMTP, so workflow emails and notifications actually get delivered

You keep full root access. It's your instance and your data, exportable any time. Billing is a flat fee on top of compute, not per workflow, per execution or per user, so adding more automations and more team members doesn't grow the bill.

That last point matters for AI automations in particular. Agents tend to run many executions, and per execution pricing on hosted automation platforms grows quickly as usage takes off. With a dedicated instance, your cost is the instance, however many times your agent runs.

Moving your workflows over

If you already built workflows locally, moving them is quick:

  1. Export your workflows from your local n8n, from the workflow menu or with the CLI: 
n8n export:workflow --all --output=workflows.json
Enter fullscreen mode Exit fullscreen mode
  1. Deploy n8n on Elestio and open the URL it gives you. Create your owner account.
  2. Import the workflows through the n8n interface.
  3. Recreate credentials in the new instance. Credentials are encrypted with your local instance's key, so adding them fresh is the clean approach, and a good moment to create production API keys separate from your test ones.
  4. Update webhooks. Triggers like Telegram register against the new HTTPS URL as soon as you activate the workflows.

Activate, send a test message, and your automation is live on infrastructure that is backed up, patched and watched.

Getting started takes minutes, not a sprint

Pick n8n from the catalog, choose a region, and Elestio provisions it with HTTPS, backups, monitoring, updates and a firewall already configured. No reverse proxy to set up, no backup script to write, no certificate renewal to remember.

Most teams have their first app running in under ten minutes.

Try Elestio free →

You can also go straight to the n8n template: fully managed n8n on Elestio.

Takeaway

AI automations are only as good as the server they run on. HTTPS, Postgres, a protected encryption key, pruning, tested backups, updates and monitoring are what turn a working workflow into a service you can rely on. Elestio handles that whole layer from day one, so your time goes into building better workflows and agents, not keeping the server underneath them alive.

Keep reading

Let's stay in touch

I'm Amit Shukla, a software engineer working across DevOps, cloud and applied AI. Behind the Stack is where I write up the things I learn the hard way, with working code and honest tradeoffs.

If this saved you some time, a reaction or a comment helps more people find it.

Top comments (1)

Collapse
 
fun_fun_19313eced54af3c68 profile image
SoloAgentFlow •

Good point that the encryption key plus the database unlocks every credential. The flip side bites people on restore: if you back up Postgres but not N8N_ENCRYPTION_KEY, the restored instance can't decrypt any credentials and every workflow fails at once. Worth storing the key separately from the DB backups and doing one test restore to a throwaway instance before you actually need it. A simple external uptime check that hits a dedicated health webhook also catches the expired-cert case you mention before customers do.