Hiring someone to set up self-hosted n8n: what to hand over and where it runs

The short answer

Self-hosted n8n is a good choice when you run a lot of workflows, want the data on infrastructure you control, or want to avoid per-run charges. The price is that you now own a server. The freelancer can set it up in days; somebody has to keep it awake, backed up and updated for years.

So when you hire someone to set it up, the build is the easy part to judge. What you need to agree before ordering is three things: where it runs, which accounts are yours, and what you get back at handover so that the next person, or you, can keep it alive. If the answers are vague, a hosted plan may be the cheaper choice in total. The comparison of n8n, Make, Zapier and code covers when self-hosting pays off at all; this guide assumes you have already decided it does.

What “self-hosted” actually hands you

With a hosted automation tool, the vendor keeps the machine running, stores the credentials, backs up the data and installs updates. With self-hosted n8n, each of those becomes a line in your own to-do list:

• A machine that is always on, reachable from the internet if any workflow starts from a webhook (a URL another app calls when something happens; see what a webhook is).
• A domain and HTTPS for that webhook address.
• A database holding your workflows, credentials and run history.
• An encryption key. According to n8n’s documentation, n8n creates a random key on first launch, saves it in its data folder, and uses it to encrypt credentials before saving them to the database.
• Backups. n8n’s documentation is explicit that a command-line export contains workflows and credentials only, and not the encryption key, users, run history or settings. To recover a whole instance you also need the data folder (or the external database) and the deployment configuration.
• Updates. n8n recommends updating at least once a month, checking the release notes for breaking changes first, and testing the update on a separate instance.

None of this is hard for a competent freelancer. All of it is easy to leave out of a quote, because none of it shows up in a demo.

Where it runs decides what breaks

My own scheduled jobs are not n8n; they are scripts on a home machine, started by the operating system’s scheduler. But the problems I hit had nothing to do with the tool and everything to do with where it ran, and they apply to a self-hosted n8n box in exactly the same way.

A machine that sleeps misses its schedule. My laptop dropped into a low-power standby the moment the screen turned off. In one 24-hour stretch, one publishing slot ran 38 minutes late, a later one did not run at all, and a morning one ran three hours late. The scheduler’s “wake the computer to run this task” option was simply ignored in that standby mode. The fix was a small background process that keeps the system awake while it is plugged in. The full story is in my scheduled jobs and sleep mode note.

A fix that needs admin rights may not be possible. Starting that keep-awake process at logon through the scheduler required administrator rights, which the account did not have. I used the startup folder instead. On a server the same question comes up: who has the admin login, and is it you?

A launcher can fail without a sound. The file that starts the keep-awake process at logon silently did nothing when it was saved in the wrong text encoding, because its path contains non-English characters. A failure where nothing at all happens is hard to notice, so my notes for that file now say to check the encoding every time it is edited.

Credentials expire on a server too. A code-hosting token on my machine stopped working. Five publishing slots over two days produced nothing, and my automatic backup push stopped for the same reason, while every scheduled task still reported success. A daily check of that login now runs every morning.

What this means for your decision:

Where n8n runs	Usually fits when	What you must ask
A computer in your office or home	Testing, or jobs where a late run does not matter	Does it sleep, restart for updates or lose network? What happens to a missed run?
A rented server (VPS)	Always-on jobs, webhooks, data kept in your account	Who patches it, who backs it up, who has the admin login?
n8n’s own cloud plan	You want n8n but not a server	Is the plan’s usage limit enough at your volume, and is the account yours?

Accounts: yours, from the first day

This is the same rule as for any automation, and it matters more when there is a server. The hosting account, the domain, the database and every connected app’s credentials should sit in accounts you own and pay for. The freelancer gets access you can remove.

The one self-hosting item that is easy to miss is the encryption key. If it only exists on the server and the server is lost, your backup of the database brings back workflows whose saved credentials nobody can decrypt. Ask the freelancer to set the key explicitly and hand you a copy for your own password manager on day one, not at the end.

If you want someone whose gigs focus on this, Get Efficient builds custom n8n workflows on a platform you own, self-hosted or n8n Cloud. Whoever you hire, put the account question in the first message and read how they answer it.

The handover checklist

Items 3, 4 and 6 are the ones most often missing, because the build works fine without them. They only matter the day something goes wrong, which is also the day the freelancer may be busy.

A message you can copy

I would like n8n self-hosted on accounts I own. Before I order:

1. Where would you run it, and why that option for my volume and webhooks?
2. What will the server, domain and backups cost per month on my accounts?
3. How will I receive the encryption key and admin logins?
4. How do you back up the whole instance, and can we test one restore before acceptance?
5. Who updates n8n after delivery, how often, and at what rate?

The answer to question 5 belongs in your maintenance terms. Paste the rest into the Handover and Maintenance fields of the workflow automation brief.

Where it goes wrong anyway

• Nobody owns updates. The server runs happily for months on an old version, then a connected app changes and the fix needs an update across many versions at once. This is the case n8n’s advice to update monthly is meant to prevent.
• The disk fills. Run history is stored in the database. If nobody set a limit on how long it is kept, a busy instance keeps growing. Ask how old run data is cleaned up.
• The backup was never restored. A backup that has not been restored once is a hope, not a backup. Make the test restore part of acceptance.

Wrap-up

Self-hosting n8n trades a platform bill for a server you own. That is a good trade only if the server is always on, the accounts and encryption key are yours, and someone is named for backups and updates. Agree where it runs before the build, collect the key and logins on day one, and accept it only after a restore test and a few unattended runs.