Ghost‑CLI In‑Place Upgrade vs Docker Blue‑Green: Which Minimizes Downtime for a Small Site?

Answer to the Question

For a single‑node Ghost CMS that uses SQLite and a simple process manager, the Docker blue‑green workflow generally provides the lowest measurable downtime and the smallest latency spike. The CLI method always stops the Node process, causing a 1–3 s outage that can be felt by active sessions. Blue‑green eliminates that single stop‑start by routing traffic to a freshly started container, so the user sees no interruption as long as the load balancer can switch instantly.

Confirmed Facts

• Ghost‑CLI’s ghost upgrade stops the Node process, then restarts it; the restart latency is deterministic but depends on the size of the installation and migrations.
• Docker blue‑green spins up a new container, performs health checks, and then updates the reverse proxy or load balancer to point to the new instance. If the balancer supports instant fail‑over, the old container is stopped only after traffic has been rerouted.
• Operationally, the CLI upgrade is a single command (ghost upgrade) with no need for container orchestration or load‑balancer re‑configuration.
• Blue‑green requires maintaining a container runtime, building/pushing a new image, and configuring the proxy to switch traffic, but it removes the single stop‑start event that can cause a latency spike.
• During the switch, two instances run concurrently, doubling resource usage on the single node.

Likely Explanation

Because the CLI upgrade always stops the process, any request that arrives during those 1–3 seconds will fail or time out, potentially breaking user sessions or causing a visible “down” state. Blue‑green avoids this by keeping the old instance alive until the new one is healthy, so the switch is effectively invisible to the user.

Steps for a Small Team

1. Ghost‑CLI Upgrade (quick, low overhead)
   • Back up the SQLite file: cp /var/www/ghost/content/data/ghost.db /var/www/ghost/content/data/ghost.db.bak
   • Run the upgrade: cd /var/www/ghost && ghost upgrade
   • Restart the process manager if it doesn’t automatically restart: systemctl restart ghost or pm2 restart ghost
   • Verify the site is reachable: curl -Is https://your-site.com | head -1
2. Docker Blue‑Green (higher effort, lower latency)
   • Build the new image: docker build -t ghost:latest .
   • Push to a registry if needed: docker push your-registry/ghost:latest
   • Start the new container with the same data volume: docker run -d --name ghost-new -v /var/www/ghost/content:/var/www/ghost/content -p 8081:2368 ghost:latest
   • Run a health check (e.g., curl -s http://localhost:8081/) until it returns 200.
   • Update the reverse proxy (Nginx, Caddy, etc.) to point location / to http://ghost-new:2368 and reload the config (nginx -s reload).
   • Stop the old container: docker stop ghost-old && docker rm ghost-old.
   • Rename the new container to the original name if desired: docker rename ghost-new ghost-old.
   • Verify the site is still reachable.

Missing Diagnostic Detail

To fine‑tune the recommendation, could you share the health‑check interval and fail‑over latency of your current load balancer or reverse proxy? If the health‑check is longer than the upgrade time, the blue‑green method may still introduce a brief outage.