An incorrect restart command in n8n can wipe every workflow you have built, break the webhook URLs your CRM calls. Or leave a Docker container stuck in a restart loop while automations queue up unprocessed.
These are the most common production incidents reported on the n8n community forum.
They almost always come from three causes: running the wrong restart command for the install method, missing a persistent volume mount, or forgetting to reload the reverse proxy on a VPS.
This guide covers the exact restart commands for every install type, the configuration choices that decide whether your data survives, and what to do when n8n refuses to come back online. The commands work the same on a local Linux machine and a VPS, with two important additions for remote servers.
1. Identify your n8n install type, then run the right command
The first mistake most people make is running docker restart n8n when n8n is running through PM2, or sudo systemctl restart n8n when there is no systemd service. Neither command throws an error. Neither restarts anything either.
Run these checks in order before any restart:
| Command to Run | What It Tells You |
|---|---|
docker ps shows n8n |
n8n is running inside a Docker container. |
pm2 list shows n8n |
n8n is running as a PM2-managed Node.js process. |
systemctl status n8n returns active |
n8n is running as a systemd service. |
which n8n points to /usr/local/bin |
n8n was installed globally using npm. |
If you cannot remember how you installed it, there is a Docker container. That is how most production n8n instances on Indian VPS servers have been deployed in 2026.
2. Restart commands for Linux setups
For anyone running self-hosted n8n on Linux directly (Ubuntu, Debian, Rocky), the n8n restart command depends on which process manager keeps the service alive between reboots.
i. systemd
The cleanest restart for n8n on Ubuntu Linux:
sudo systemctl restart n8n
sudo journalctl -u n8n -f
The journalctl tail in a second terminal catches startup errors as they happen. If the service does not return to active (running) within 10 seconds, the logs will show why.
ii. PM2
pm2 restart n8n
pm2 save
The pm2 save step is what beginners skip. Without it, the change is in memory only. After the next server reboot, PM2 loads its previously saved state, and your changes vanish.
iii. Direct Node.js
If n8n is running because you typed “n8n start” in a terminal, restarting means stopping with Ctrl+C and running it again. This setup dies the moment your SSH session disconnects, so it belongs on a developer laptop, not a server.
3. Restart commands for Docker setups
Docker offers two restart patterns that look almost identical but behave very differently. Picking the wrong one is the second-most common reason n8n instances break in production.
i. Warm restart (container preserved)
docker restart n8n
For Docker Compose setups:
docker-compose restart
This restarts the existing n8n Docker container using the same image and configuration. Reach for it after changing an environment variable inside the container or to clear stuck workflow executions sitting in the queue.
ii. Cold restart (container recreated)
docker-compose down
docker-compose up -d
This destroys the container and creates a fresh one from the image. Use it when:
- You edited docker-compose.yml
- You pulled a new n8n image with docker-compose pull
- The container is wedged, and a warm restart did not fix it
A cold restart is also the only way to pick up volume mount changes. If your original docker-compose.yml did not include a volume and you just added one, a warm restart will not save your workflows on the next cycle. The volume only attaches when the container is recreated.
iii. Update-and-restart sequence
To upgrade n8n and restart cleanly in one operation:
docker-compose pull
docker-compose down
docker-compose up -d
docker-compose logs -f n8n
The trailing log tail captures database migration warnings in Postgres-backed setups, where most failed upgrades first surface.
4. Restart workflow on a VPS server
All the commands above work the same way over SSH. Two things change on a VPS that do not apply to a local install.
The reverse proxy reload. Your n8n on a VPS sits behind Nginx, Traefik, or Caddy for SSL termination. These proxies cache upstream connections to the n8n container. After the n8n restart command finishes, reload the proxy so it drops the stale connections:
sudo nginx -t && sudo systemctl reload nginx
The nginx -t validates the config before applying it. Skip this step, and a typo can take down every site on the server, not just n8n.
Verify from outside the VPS. SSH back to your own machine and curl the public URL, not localhost, from inside the server:
curl -I https://n8n.yourdomain.com
The response code tells you exactly which layer is failing:
- 200 OK – n8n, Nginx, SSL, and DNS are all aligned
- 502 Bad Gateway – Nginx is up, but cannot reach n8n on its port
- 503 Service Unavailable – n8n is starting and not yet ready
- 404 Not Found – your WEBHOOK_URL does not match the public domain
5. Why workflows disappear after a restart (and how to prevent it)
Three configuration choices determine whether a restart preserves or destroys your data. Get all three right once, and you can restart n8n without losing workflows for the rest of the instance’s life.
i. Volume mount on the data directory
In docker-compose.yml:
services:
services:
n8n:
image: n8nio/n8n:1.103.2
restart: unless-stopped
volumes:
- n8n_data:/home/node/.n8n
volumes:
n8n_data:
The named volume n8n_data lives outside the container’s file system. When the container is destroyed with docker-compose down, the volume persists. The new container reads the same workflows, credentials, and execution history on startup.
ii. PostgreSQL instead of SQLite
SQLite is the default. It stores everything in a single file in the data directory, locks during concurrent execution, and corrupts faster than people expect. For any production setup running more than a handful of workflows, switch the database:
environment:
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
- DB_POSTGRESDB_PORT=5432
- DB_POSTGRESDB_DATABASE=n8n
- DB_POSTGRESDB_USER=n8n
- DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
The Postgres container needs its own named volume for the same persistence reason. Without it, your database survives container restarts but not container recreation.
iii. A permanent encryption key
N8N_ENCRYPTION_KEY is the one environment variable that, if changed, will not throw an error but will silently make every saved credential unreadable. Generate a 32+ character random string once, store it in a password manager, and never let it change. Losing this key means re-entering every API token in every credential, manually, with no recovery path.
6. Fix n8n not coming back online after a restart
Work through these in order. The cause is usually one of the first three rows.
| Symptom | Run This | What It Tells You |
|---|---|---|
| Container exits within seconds | docker logs n8n --tail 100 |
Usually indicates a typo or invalid value in an environment variable. |
| Login screen asks for a new owner account | docker volume inspect n8n_data |
The Docker volume is unmounted, missing, or empty, so n8n cannot find its existing data. |
| Webhook returns 404 | Check WEBHOOK_URL in .env |
The configured webhook URL does not match your public domain. |
| 502 from Nginx | docker ps then curl localhost:5678 |
n8n is not listening on port 5678 or the container is not running. |
| Credentials show as “invalid” | Compare the current N8N_ENCRYPTION_KEY with your backup. |
The encryption key has changed between restarts, so stored credentials can no longer be decrypted. |
| SSL certificate error | sudo certbot renew --dry-run |
The SSL certificate has expired or renewal is failing. |
| Postgres connection refused | docker logs postgres |
PostgreSQL is not ready or failed to start before n8n attempted to connect. |
One non-obvious case worth flagging: when active workflows do not fire their triggers immediately after a Docker cold restart, the cause is trigger re-registration timing. n8n re-registers webhook listeners on startup, and any external service calling those webhooks during the first 30 seconds will get a 404. Toggling the workflow off and on from the dashboard forces an immediate re-registration.
For the Postgres race condition (the last row above), add a health check to your docker-compose.yml:
depends_on:
postgres:
condition: service_healthy
7. VPS specs n8n actually needs
The official n8n recommendation lists 1 GB RAM. The practical floor for production is higher than that.
- 2 GB RAM handles light workflows under 100 executions per day
- 4 GB RAM suits moderate use with 5–10 active workflows
- 8 GB RAM or more is needed for high-volume webhooks, image processing, or AI workflow nodes
- 2 vCPU minimum. Single-core plans throttle Postgres and Node.js simultaneously
- NVMe SSD storage matters more than disk capacity. Workflow executions write to disk continuously
- Indian data centre if your external services (Razorpay, WhatsApp Business, Shopify India) and end users sit in India. Webhook round-trip times under 50ms keep automations feeling instant
The best VPS hosting for n8n is one that ships with Docker pre-installed, supports Docker Compose out of the box, and provides root SSH access. Shared hosting cannot run n8n because it locks down container runtimes and port binding. Docker VPS hosting is the practical floor.
Conclusion
The pattern that prevents most n8n restart problems comes down to three habits worth building into the initial setup, rather than adding them later in a panic.
Never use n8nio/n8n:latest in production, because the next time you pull, you have no idea which version you are about to run. Mount a named volume on /home/node/.n8n and a second one on the Postgres data directory. Store your encryption key somewhere that survives the destruction of every server you currently own.
Pick the right command for the install type, reload Nginx if it sits in front, watch the logs for 30 seconds, and curl the public URL from outside the box. Once these become routine, n8n stops being a fragile production dependency and becomes one of the more boring parts of the stack, which is exactly what an automation platform should be.
FAQs
Yes, but in-flight executions will be marked as failed in the Executions tab. The partial run is recorded in the database. If your workflow is idempotent, re-trigger it manually after the restart. For payment processing or webhook-driven flows that cannot afford a failed run, schedule restarts during a low-traffic window.
The container is crashing on startup, and Docker’s restart policy keeps recreating it in a loop. Run docker logs n8n –tail 200 to see the exit reason. The two most common causes are a Postgres connection failure (Postgres is not ready before n8n starts) and a missing or malformed environment variable. The fix for the first is the health-check dependency shown in section 6.
Stop the new container, change the image tag in docker-compose.yml back to the previous version, then run docker-compose up -d. This only works if you pinned versions before the upgrade. If you used the latest, the previous image was already overwritten by the pull.
Yes. Toggle the workflow between Active and Inactive from the dashboard. This re-registers its triggers and reconnects its webhooks without touching the rest of your automations. Use this when one workflow misbehaves, but the n8n service itself is healthy.
A warm Docker restart finishes in 5 to 15 seconds. A cold restart with a fresh container takes 20 to 45 seconds, depending on volume size and database migration steps. systemd and PM2 restarts complete in under 10 seconds.
The n8n UI has no restart button. The dashboard can deactivate workflows, but restarting the underlying service always happens at the OS or container layer. Command-line restarts are the only path
