n8n Docker Not Starting? Here’s How I Fixed It

I was three workflows deep into automating my home assistant backups when my n8n Docker container stopped responding. Nothing in the logs. The container would spin up, hang for 30 seconds, then exit with code 1. No error message. Just gone. If you’re troubleshooting n8n Docker issues, you’ve probably hit something similar—a vague failure that gives you nothing to work with. This is what I found.

The Initial Setup Looked Fine

My docker-compose.yml was straightforward enough. I’d pulled it from the n8n docs, changed a few paths, and deployed it alongside my other services. The container logs showed n8n initializing its SQLite database, then nothing. No error. Just a clean exit.

First instinct: rebuild. docker-compose down && docker-compose up. Same result. Then I tried pulling a fresh image. Still nothing. At this point I needed actual error output, not just “container exited.”

docker-compose logs -f n8n

That showed me the initialization was completing, but then the service was exiting cleanly. Not crashing—exiting. That’s different. That usually means the main process finished and nothing was keeping the container alive.

Error 1: Missing or Incorrect Database Connection String

n8n needs a database. By default it uses SQLite, which is fine for small homelabs, but it needs the right environment variables and the right permissions on the data directory. I had mounted a volume, but the path was wrong in my compose file.

My docker-compose had this:

services:
  n8n:
    image: n8nio/n8n:latest
    environment:
      - DB_TYPE=sqlite
      - DB_SQLITE_PATH=/data/n8n.db
    volumes:
      - ./data:/data
    ports:
      - "5678:5678"

Looks right. But the ./data directory didn’t have the right permissions. The n8n container runs as user 1000 inside the container, and my data folder was owned by root on the host. The database file couldn’t be created, so the initialization failed silently and the process exited.

Fix: change directory ownership before starting:

mkdir -p ./data
chown 1000:1000 ./data
docker-compose up -d n8n

That was error one. Container stayed running this time. But it didn’t respond on port 5678.

Error 2: Port Already in Use or Firewall Blocking

Port 5678 was already claimed. I run a lot of services, and something else had grabbed it. I should have checked first.

netstat -tulpn | grep 5678

Nothing was listening on 5678 itself, so it wasn’t a port conflict on the host. But the container wasn’t actually binding to the port. I checked the container’s network:

docker inspect n8n_n8n_1 | grep -A 10 NetworkSettings

The container was on the right network. So the issue was actually the N8N_HOST environment variable. By default, n8n listens on localhost inside the container, which means it won’t answer requests from outside the container. That’s a security feature, but it breaks access from the host.

Add this to your environment:

environment:
  - N8N_HOST=0.0.0.0
  - N8N_PORT=5678
  - N8N_PROTOCOL=http
  - WEBHOOK_URL=http://your-server-ip:5678/

The WEBHOOK_URL matters if you’re using n8n’s webhook nodes. That URL is what external services will call back to. If it points to localhost and something outside your homelab tries to trigger a workflow, it won’t reach you.

After setting those variables, I could actually see the login page. Progress.

Error 3: Workflows Fail with “Connection Refused” on First Run

Got into n8n, created a simple workflow that hit a local Home Assistant instance on 192.168.1.50:8123. Executed it. Failed instantly: “connection refused.”

n8n container couldn’t reach my Home Assistant service. That’s a Docker network issue, not an n8n issue, but it’s worth mentioning because it comes up immediately when you try your first integration.

The n8n container is isolated from the host network by default. If you’re using the default bridge network, it can’t reach services on your host’s IP address. You have a few options: use host network mode (simplest for a homelab, less secure), use a custom Docker network that bridges all your services, or use the host’s gateway IP (172.17.0.1 from inside a standard bridge container).

I chose the custom network approach:

networks:
  homelab:
    driver: bridge

services:
  n8n:
    image: n8nio/n8n:latest
    networks:
      - homelab
    # ... rest of config

  home-assistant:
    image: ghcr.io/home-assistant/home-assistant:latest
    networks:
      - homelab
    # ... rest of config

Once both services were on the same network, n8n could reach Home Assistant by hostname (the service name). That fixed the connection refused error for any local service.

Error 4: Workflows Timeout or Hang Silently

A workflow that calls an external API would start executing and then just… stop. No error. The execution showed “running” for 2 minutes, then nothing. Not a timeout message, not a failure. Just hung.

This happened when I was trying to chain multiple HTTP requests together. The n8n logs showed nothing unusual. The workflow just stalled mid-execution.

Turns out my n8n container didn’t have enough memory. I’d given it 512MB, which is tight for n8n plus running a couple of JavaScript expressions. Docker was silently killing threads when memory pressure hit. The execution would hang waiting for a response that was never coming because the worker thread was dead.

Docker-compose memory limits:

services:
  n8n:
    image: n8nio/n8n:latest
    deploy:
      resources:
        limits:
          memory: 1G
        reservations:
          memory: 512M

That’s a reservation (soft limit, Docker will allocate more if available) of 512MB and a hard limit of 1GB. For a homelab with a couple of active workflows, 1GB is reasonable. If you’re running complex AI agent workflows with local LLMs, you might need 2GB. I bumped mine to 1.5GB and the hanging stopped.

Error 5: Database Locked or Corruption After Restart

After a few days of running, I restarted my Docker daemon. When n8n came back up, it threw this in the logs:

Error: database is locked

SQLite doesn’t handle concurrent access well, and if a process crashes or the container exits uncleanly, the database can get left in a locked state. The next startup can’t get a write lock on the database file.

Quick fix: remove the lock file and let SQLite recreate it:

rm ./data/n8n.db-wal
rm ./data/n8n.db-shm
docker-compose up -d n8n

Those .wal and .shm files are SQLite’s write-ahead log and shared memory files. They’re temporary, and if they’re left behind from an unclean shutdown, they can cause issues. Removing them is safe—you’ll just lose any uncommitted transactions from before the crash.

If the issue happens repeatedly, it’s a sign you should switch to PostgreSQL instead of SQLite. PostgreSQL handles concurrent writes properly and won’t lock up on you. I haven’t had to do that yet, but it’s on my list for when I get serious about AI agent workflows that might spawn multiple parallel executions.

The Actual Stable Setup

After working through those five issues, here’s what my working docker-compose looks like:

version: '3.8'

services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    environment:
      - DB_TYPE=sqlite
      - DB_SQLITE_PATH=/data/n8n.db
      - N8N_HOST=0.0.0.0
      - N8N_PORT=5678
      - N8N_PROTOCOL=http
      - WEBHOOK_URL=http://192.168.1.100:5678/
      - TZ=UTC
    ports:
      - "5678:5678"
    volumes:
      - ./data:/data
    networks:
      - homelab
    deploy:
      resources:
        limits:
          memory: 1.5G
        reservations:
          memory: 512M

networks:
  homelab:
    driver: bridge

It’s been running for two months without issues. The key things: proper directory permissions, correct host/port bindings, shared Docker network for local service access, adequate memory allocation, and keeping the database files clean if something crashes.

One thing that still surprises me about n8n: the AI agent node is genuinely useful once you get the basics working. I built a workflow that monitors my server load and decides whether to trigger a backup, scale something down, or just log it. No if-then statements—the agent actually reasons about what to do. That took me a while to trust, but it works. The whole point of self-hosting is having something that’s actually yours, running on your hardware, doing what you tell it to. n8n, once you get past the initial setup friction, delivers on that.

FAQ

Can n8n run on a Raspberry Pi?

Technically yes, but not well. A Pi 4 with 4GB RAM can run n8n in single-workflow mode, but it gets sluggish with multiple parallel executions. A Pi 5 with 8GB would be better. For anything serious, run it on a server with at least 2GB RAM dedicated to the container.

Do I need PostgreSQL or can I use SQLite?

SQLite works fine for homelabs with light to moderate workflow use (under 10 concurrent executions). For heavy automation or multiple agents running in parallel, switch to PostgreSQL. It handles locking better and scales without the database lock issues you’ll hit with SQLite.

Can n8n access services on my local network?

Yes, but only if you put the n8n container on a shared Docker network with those services, or use host network mode. By default, Docker isolates containers. Use service names (like home-assistant:8123) instead of IP addresses once they’re on the same custom network.

How do I backup my n8n workflows?

Your workflows are stored in the SQLite database inside the /data directory. Back up that entire directory. You can also export individual workflows from the UI, but the database backup is the full solution. Use docker cp or mount the directory to an automated backup tool.

What’s the difference between n8n and Make or Zapier?

n8n is self-hosted and open source. Make and Zapier are cloud-only and you pay per task executed. For a homelab, n8n costs nothing to run (besides electricity) and keeps your data on your hardware. The tradeoff is you manage the infrastructure and don’t get their managed reliability guarantees.

Explore n8n in our AI Homelab Toolkit.