Questions
Sorted by how likely you are to hit it, not by topic. The first three are the ones that cost people real work.
All of them
Can I run more than one copy for reliability?
No. Keep it at one. Two copies of n8n both fire every schedule and both answer every trigger, so your workflows run twice and logging in behaves strangely. One instance is the correct setup here.
Running n8n across several copies needs its queue mode, which needs a piece of infrastructure we do not offer today. The size controls let you make one instance bigger, and that is the right lever. If you see an option to add extra instances, leave it at one for this app.
Where did my saved credentials go?
On a self-hosted setup this is almost always the encryption key. n8n encrypts every credential with one key, and if that key is not stored somewhere permanent it is regenerated on restart, leaving credentials that nothing can read.
Here the key is generated once and kept for you, so there is no step to skip and nothing to lose. The full explanation, including how to recover it on your own machine, is on its own page.
My workflows disappeared. What happened?
Something was storing them somewhere temporary. n8n keeps everything in one place, and if that place does not survive a restart then a restart is a factory reset.
Turning on a database afterwards does not bring anything back, it gives you an empty one. Instances deployed from this page get a managed database attached before the first boot, so there is no tick box to miss.
What does it actually cost, and can I cancel?
Twenty dollars a month for the setup we recommend: ten for a gigabyte of app power, ten for a gigabyte of dedicated database memory. Billing is monthly and you can cancel whenever you like. You are buying capacity rather than a plan, so there are no per-run charges and no execution limits to watch.
A managed database is included on every account at no charge. The second ten dollars buys that database dedicated memory, which is query speed rather than the database itself, and it is what Dockhold's own deploy guide for n8n recommends. Capacity is yours to split: buy a gigabyte for n8n, want something else running later, and you divide what you already have rather than buying a second plan.
Will the free allowance run n8n?
No, and we would rather say so here than let you find out. The free allowance is real and it is genuinely useful for smaller apps, but n8n needs more memory than it includes.
That is why every price on this page is a real price and why the word free does not appear next to the deploy button.
Do I need a GitHub account, or to fork anything?
No. Sign in with Google. You are deploying from a public starting point that we maintain, and nothing is copied into an account of yours.
Forking is only worth doing if you want to pin your own version of n8n or bundle extra community nodes into the image. Both are explained on the setup page.
Who can reach my instance?
By default, anyone who knows the address, which is why the first thing n8n asks you to do is create an owner account with a password. Nothing is open before you set that.
Any account that has bought compute, which includes every setup on this page, can also switch the app to private. A private app is reachable only with a token you control, checked at the edge before the request ever reaches n8n. That is a Dockhold setting rather than an n8n one.
How do I update n8n, and do you do it for me?
No, and that is deliberate. Your instance runs a pinned version and it does not change underneath you. You choose when to move, and you do it by redeploying.
Moving up is a redeploy from your app's page. It rebuilds from the starting point and picks up whatever version that currently pins, and your workflows and credentials are in the managed database so they survive it. To control the version exactly, fork the starting point and pin the tag you want. Upgrades change n8n's own database in a direction that does not reverse, so export before you do one. We keep the platform underneath patched either way.
What do you support, exactly?
We keep the instance running: it stays online, it restarts if it falls over, the platform under it stays patched, and the database is managed. The workflows are yours and we do not build or debug them.
That is not us being unhelpful, it is the deal this audience actually wants. For questions about n8n itself, its community is excellent and answers faster than any vendor would.
Can I use my own domain?
Yes. Add the domain in the app settings, point one DNS record at us, and the certificate is handled for you. The n8n side follows automatically.
Do it early if you are going to do it, because integrations you have already registered keep pointing at the old address.
Can I move to my own server later?
Yes, and we will not make it awkward. Export your workflows and credentials from inside n8n and import them wherever you like. It is standard n8n, not a special version of it.
One of the starting workflows does exactly this on a schedule, pushing every workflow as a file to a repository you own. Building it is the fastest way to prove the door is unlocked.
Can I use the AI nodes?
Yes. You bring your own key for whichever provider you use, and it is stored as an n8n credential like any other.
AI steps and file handling are what actually consume memory in n8n, so if you plan to lean on them, start at the recommended size rather than below it.
Can I install community nodes?
Only by building them into your own copy of the starting point. Anything installed into a running instance at runtime is lost on the next restart, so it would work today and vanish tomorrow.
Fork the starter, add the packages to the image, deploy from your fork. The setup page has the steps.
What about backups?
Export your workflows from inside n8n, on a schedule, to somewhere you control. That is the backup we would tell a friend to have, and it is the one that also works when you decide to leave.
We are not going to claim a restore button we have not shown you working. The managed database is a managed database rather than an archive, so do not treat it as your only copy of a year of work. n8n's own export is the copy that is genuinely yours, and one of the starting workflows does it on a schedule.
What happens if I stop paying?
A failed payment opens a seven day window, and you get an email saying so with the date it closes. Nothing changes during it. If the window closes, your account drops back to the free allowance: your oldest app is kept running at the free size and anything else is paused.
Paused is not deleted. Your apps, workflows and database are still there, and updating your billing restores everything. Worth knowing for this app specifically: n8n needs more than the free size, so it will not run well at that point even if it is the app that gets kept. Export your workflows before it comes to that, which is good advice on any host.
Why does the first deploy take a few minutes?
Because your instance is being built for you rather than handed to you from a pool. It happens once. Restarts after that are quick.
Can you see my data?
Your instance runs in its own isolated environment. Your workflows and the data flowing through them are yours, and we do not read them.
It runs on its own isolated node pool, with no route to the rest of the platform and a default-deny network policy around it. What Dockhold holds about you, and why, is set out in full on the trust page rather than paraphrased here.
Is this allowed under n8n's licence?
Yes, for the ordinary case. n8n ships under the Sustainable Use License, which lets you run your own instance for your own or your business's automations, including building workflows for clients.
What it does not let you do is resell access to it or white-label it as your own product without a commercial licence from n8n. You are the operator of your instance, so that is your call to make. We are not offering n8n as a service, and every instance is deployed by its owner from a public starting point.
What port does it listen on, and do I configure it?
You do not. The platform tells the app which port to use and the starting point listens on it.
How does it connect to the database?
The connection details are handed to the app when it starts, and the starting point reads them. There is nothing to type and no password for you to hold.
Pointing it at a database of your own somewhere else is not supported today.
Do you support queue mode and workers?
Not today. Queue mode needs a piece of infrastructure the platform does not offer yet, which is also why the answer to running two copies is no.
Where are the logs?
In the Dockhold dashboard, on the app's page. There is also a tool for reading them from an AI assistant if that is how you work.
Can I do this whole thing from an AI assistant?
Yes. There is a page written for exactly that, with the deploy target, the settings and the tools to call, in order.