Workflow automation your own team writes, running next to the systems it talks to instead of reaching them across the internet. Pilae runs it on your own servers, or in Zurich, Switzerland, and eleven other Pilae Cloud regions.
- Licence
- Sustainable Use
- Runs on
- Your own hardware, or any of 10+ Pilae regions — six of them in Switzerland and the EU
- Upgrades
- Pinned, tested against your configuration, applied in your window
- Upstream
- n8n.io
Running n8n in production: what it takes
Pin and deploy
The version in our recipe, not whatever latest resolves to on the day, with Postgres behind it rather than the default SQLite file.
Turn on queue mode
Redis and separate worker containers, so one slow workflow cannot stall the rest and so a second worker is a scale decision rather than a rebuild.
Separate the encryption key
You hold the credential key. We back it up to a target you own, separate from the database, so restoring one does not hand over the other.
Back up and restore on a schedule
We take the database and the key offsite nightly. Once a month we restore both into a scratch environment and run a workflow there.
Upgrade in your window
n8n releases weekly, and the behaviour of individual workflow steps does change between minor releases. We hold your pinned version, test the next one against a copy of your workflows, and move you in the window you agreed.
What n8n is, and who runs it
n8n is a workflow tool. You wire a trigger to a sequence of steps — call an API, transform the result, branch on it, write it somewhere — in a visual editor, and drop into JavaScript for the step that does not fit a node. It covers the same ground as Zapier or Make, with one structural difference: it runs on your own machine.
That difference is the point. An automation platform is, by nature, the thing holding credentials to everything else: the CRM, the accounting system, the file share, the mail relay. Running it as SaaS means those credentials live with a vendor and every workflow reaches your internal systems from outside. Running it yourself means the automation sits next to what it automates, and the systems that were never meant to face the internet do not have to.
It is also the app on this list we run hardest ourselves, which is why the operational advice here is specific rather than general. The default SQLite database is pleasant until the first restore. Without queue mode, one workflow polling a slow API stalls every other trigger on the box. Execution history grows without bound unless pruning is configured. And the encryption key that protects every stored credential is, by default, sitting in the same backup as the database it protects.
One thing to be clear about: n8n is not open source, and the note below sets out what its licence allows. For internal automation that costs nothing. We would rather write that here than have it surface in a procurement review.
n8n system requirements
Before anything is deployed, this is what has to exist. We size it with you in the first session, and we say so when your own hardware is already enough.
- CPU and memory
- 2 vCPU · 4 GBFor the main node. Real volume wants queue mode and separate workers, which is the same image again.
- Database
- PostgreSQLSQLite is the default and is fine until the first time you want a second node or a clean restore.
- Queue
- RedisRequired for queue mode. Without it one process does triggers and execution both, and a slow workflow blocks the rest.
- Encryption key
- 1 key, stored apartIt encrypts every saved credential and you hold it. Backed up separately from the database, because one file holding both leaks everything.
- DNS and TLS
- 1 hostnameReachable by whatever calls your webhooks. Certificate issuance and renewal are automated end to end.
Migrating from Zapier to n8n
Zapier workflows do not convert. The triggers, the field mappings and the branching all have direct equivalents in n8n, but there is no import: somebody rebuilds each one. That is less daunting than it sounds, because most estates turn out to have a long tail of Zaps nobody has looked at in two years. We inventory what actually ran in the last ninety days, rebuild those, and let the rest expire with the subscription. The credentials are the part to plan around — every integration has to be re-authorised against the new host.
Count what actually runs
Execution history for the last ninety days, not the list of workflows. That list is usually much shorter than the one in the sidebar.
Rebuild the live ones
Trigger by trigger, with the same inputs fired at both systems so the outputs can be compared rather than assumed.
Re-authorise the integrations
Every connected service needs new credentials against the new host. They are encrypted with a key held in your vault, not in the database.
Run in parallel, then stop paying
Both systems stay live. The old one writes to a log instead of acting. We switch it off once a full cycle has run without error, including the monthly and quarterly jobs.
What a night of n8n executions looks like
infoexec invoice-sync: ok in 2.4s, 41 items
infobackup database and encryption key: verified offsite
infoexec crm-to-erp: ok in 0.8s, 6 items
inforestore drill from last backup: ok, 1m02s
infoexec vendor-webhook: retry 1 of 3, upstream returned 502
infoexec vendor-webhook: ok in 1.1s, 1 item
infoprune executions older than 30 days: 12,904 rows
What Pilae is responsible for
A pinned version
A version we have run, not whatever latest resolves to that day.
A runbook
What it depends on, how it fails, what to do about it. In your repository.
A restore drill
Backups restored on a schedule. A backup nobody has restored is a file.
A patch window
Security updates in a window you agreed, with a rollback ready.
Someone watching
Every endpoint probed on the minute. An alert reaches a person, not a dashboard nobody opens.
- Where it runs
- zur1, fra1, fal1, gra1, ams1, hel1, lon1, ash1, hil1, sin1, tok1, syd1, on-premZurich, Frankfurt, Falkenstein, Gravelines, Amsterdam, Helsinki, London, Ashburn, Hillsboro, Singapore, Tokyo, Sydney, Your own hardware
- Who holds the credentials
- You do. Ours are separate, named, logged and revocable with one command. We ask before anything changes outside an agreed window.
- If you leave
- The machine, the data, the compose files and the runbook are already yours. Nothing stops when our access does.
What running n8n costs
On Starter, n8n runs in Pilae Cloud for CHF 449EUR 479USD 559 a month, hosting and onboarding included. On Business, it is one of up to three apps for CHF 1,590EUR 1,690USD 1,990 a month, on your own servers or in Pilae Cloud. Enterprise is quoted. The plans set what each includes; these are the inputs that move the price around them.
- Instance size
- The CPU, memory and, where a model runs, the GPUs the app needs for your users and your data.
- High availability
- One machine with tested restores, or a replicated setup that keeps serving when a node fails.
- Storage and backups
- How much data it holds, how long backups are kept, and point-in-time recovery for its database.
- Plan and support
- Starter, Business or Enterprise: support hours, response times in the contract and how often we review the service with you.
- Region
- Your own hardware, where the infrastructure is already yours, or a Pilae Cloud region, where machines are priced per month. On Starter, Pilae chooses the site.
- Sign-on and integrations
- Single sign-on, directory sync, mail relays and the other systems the app has to reach.
n8n: common questions
Is n8n open source?
Why does it need Postgres if SQLite works?
Where are the credentials for connected systems kept?
Can it reach systems that are not on the internet?
How do you handle the weekly releases?
Also in workflow and data
NocoDB
A spreadsheet interface over a real database, so a department can build the tool it needs without anyone provisioning a new system.
Replaces Airtable
Directus
A data platform and headless CMS over your own SQL database. Editors get an admin app, and every table gets an API.
Replaces Contentful, Airtable
Windmill
Scripts, workflows and internal tools in Python, TypeScript, Go, Bash or SQL, run by workers on your own machines and operated by Pilae.
Replaces Retool Workflows
Bring us your n8n. We will tell you what it takes.
Thirty minutes on the deployment you already have, or the one you are about to start.