If you are looking for the n8n desktop app, stop looking. It was announced in 2021, never left its early stage, and the repository was archived in August 2025. It is not maintained, it does not receive security updates, and installing an old build gets you a version of n8n that is years behind. The three supported options now are npx for a quick look, Docker for a real local instance, and a hosted instance for anything that needs to stay up.
This comes up often enough to be worth answering directly, because the search results still surface the old announcement post and the archived repository, neither of which says clearly that the thing is dead. Here is what each replacement actually gives you.
Table of contents
- Why the desktop app went away
- npx, for a look in under a minute
- Docker, for a real local instance
- The local-only limitation nobody mentions first
- Where to run the always-on instance
- How this fits the rest of the stack
- FAQ
Why the desktop app went away
The desktop build was an Electron wrapper around the same Node application that runs on a server. That works for a tool you use alone, on one machine, while it is open.
It works badly for the thing most people want n8n to do. Workflows are usually triggered by something happening: a webhook arriving, a schedule firing, a record changing in another system. All of those require the instance to be running and reachable when the event occurs, and a desktop application on a laptop is neither of those things at 4am with the lid closed.
So the desktop app was permanently in tension with the product’s main use case. Maintaining a separate packaging target for a build that could not do the primary job was not a good trade, and it was retired.
The practical consequence: local means for building and testing, and something always-on means for running. That split is now explicit rather than fudged by a desktop build.
npx, for a look in under a minute
The fastest way to see n8n running, with no install and nothing left behind.
npx n8nIt downloads and starts n8n, then serves the editor on http://localhost:5678. Requires Node 18 or later.
Worth understanding what this is and is not. It uses SQLite in a local directory under your home folder, it holds no credentials securely, and it stops when you close the terminal. Webhook URLs point at localhost and are unreachable from the internet, so any workflow with an incoming trigger cannot be tested end to end without a tunnel.
Good for evaluating the interface and building a workflow you will move elsewhere. Not a place to keep anything.
Docker, for a real local instance
This is the closest replacement for what people wanted from the desktop app: n8n on your own machine, persisting between restarts.
docker volume create n8n_data
docker run -d --name n8n \
-p 5678:5678 \
-v n8n_data:/home/node/.n8n \
-e GENERIC_TIMEZONE="Europe/London" \
-e N8N_SECURE_COOKIE=false \
docker.n8n.io/n8nio/n8nThe volume is the important part. Without it, every container restart discards your workflows and credentials, which is the single most common complaint from people following a shorter version of this command.
For anything beyond experimentation, use Postgres rather than the default SQLite. SQLite is fine for a handful of workflows and becomes a bottleneck once execution history grows, because it locks on write.
services:
db:
image: postgres:16
environment:
POSTGRES_USER: n8n
POSTGRES_PASSWORD: change-me
POSTGRES_DB: n8n
volumes:
- db_data:/var/lib/postgresql/data
n8n:
image: docker.n8n.io/n8nio/n8n
ports:
- "5678:5678"
environment:
DB_TYPE: postgresdb
DB_POSTGRESDB_HOST: db
DB_POSTGRESDB_USER: n8n
DB_POSTGRESDB_PASSWORD: change-me
N8N_ENCRYPTION_KEY: generate-a-long-random-string
EXECUTIONS_DATA_PRUNE: "true"
EXECUTIONS_DATA_MAX_AGE: "336"
volumes:
- n8n_data:/home/node/.n8n
depends_on:
- db
volumes:
db_data:
n8n_data:Set the encryption key explicitly and keep it safe. It encrypts stored credentials, and losing it means every credential in the instance has to be re-entered. The pruning variables stop execution history growing without bound, which is the other thing that eventually breaks an unattended instance.
The local-only limitation nobody mentions first
You can build and run workflows locally, but two categories will not work properly, and they are the categories most workflows fall into.
Incoming webhooks need a public URL. A service calling back into your automation cannot reach localhost. For testing you can put a tunnel in front of it, which n8n supports through a tunnel flag, but that is a development aid and explicitly not for production use.
Scheduled triggers need the instance to be running when the schedule fires. A workflow set to run at 6am does not run if the machine was asleep, and it does not catch up afterwards. It simply did not happen, and nothing tells you.
This is the whole reason the desktop app was a poor fit. Any workflow that reacts to the outside world or to the clock needs somewhere that is always on and always reachable, and that is a server rather than a laptop.
The workable pattern: build and iterate locally where breaking things is cheap, then export the workflow as JSON and import it into a hosted instance for anything that runs unattended.
Where to run the always-on instance
Three options, with the trade in each.
n8n Cloud is the official managed offering, priced per execution. Nothing to operate, and you accept that workflow data transits their infrastructure, which is occasionally the blocking constraint.
A VPS you administer gives complete control at the cost of owning the whole list: TLS certificates, reverse proxy, database, backups, pruning, and version upgrades. Entirely reasonable if you already run servers.
n8n is also available as a managed tool on RunxBuild, deployed with its own plan, custom domains, environment variables, autoscaling, and logs, with a managed Postgres instance alongside it. On a $6 Basic plan with a database next to it, the certificate and the database are handled and the recurring decision is when to take an upgrade.
The choice mostly turns on whether your workflows touch data that can leave your infrastructure, and on whether anyone on the team wants to own a server. Both are answerable in about a minute, and they settle it.
How this fits the rest of the stack
The real cost of running n8n is the instance plus the Postgres it needs, and those are easier to judge as two numbers than as one bundled figure, especially when comparing against per-execution pricing. The RunxBuild hosting calculator shows the tool and its database as separate line items, alongside anything else the workflows call into.
Useful related references:
- n8n Use Cases: What It Is Genuinely Good At, and What It Is Not
- n8n Alternatives: The Honest Comparison by What You Are Escaping
- n8n AI Agent Node: What It Does and When a Plain Chain Is Better
- Services on RunxBuild
FAQ
Is there still an n8n desktop app?
No. It was announced in 2021 and the repository was archived in August 2025. It is unmaintained and receives no security updates. Use npx for a quick look, Docker for a local instance, or a hosted instance for anything unattended.
How do I run n8n locally?
Either npx n8n for a temporary instance on port 5678, or Docker with a named volume mounted at /home/node/.n8n so workflows and credentials survive restarts. Use Postgres rather than SQLite once you have more than a few workflows.
Why do my n8n workflows disappear after restarting Docker?
The container was run without a volume, so the data directory was discarded with the container. Create a volume and mount it at /home/node/.n8n.
Can I use webhooks with a local n8n instance?
Not from external services, since they cannot reach localhost. n8n offers a tunnel option for development, but it is not intended for production. Anything with an incoming webhook needs a publicly reachable instance.
What happens if I lose the n8n encryption key?
Every stored credential becomes unreadable and must be re-entered. Set N8N_ENCRYPTION_KEY explicitly rather than letting it be generated, and back it up separately from the database.