How we ship deploys in 60 seconds
A peek at the build pipeline behind every Dockfly deploy — Nixpacks, BuildKit, BoltDB, and a lot of caching.
When we say 60-second deploys, people raise an eyebrow. So here's the breakdown of what actually happens between your git push and a live app.
Step one: webhook. GitHub fires a push event the instant you ship. Our control plane gets it in ~80ms.
Step two: queue. We push a build job into Asynq (Redis-backed queue). Free workers grab it within a second.
Step three: clone. The builder pulls only the changed paths from your repo, using a shallow clone with depth 1.
Step four: build. Nixpacks figures out your stack, BuildKit reuses every layer it can, and we save the result in a per-tenant cache. First builds are slow; subsequent ones are fast.
Step five: push. The OCI image goes to our internal registry over local network — usually 1-3 seconds for a small Node app.
Step six: roll out. The control plane tells the target node to pull and run. Health check passes, traffic is shifted, old container drains for 30 seconds.
On the median app, this whole sequence completes in 45-60 seconds. The slowest piece is usually the build itself, which is why we obsess over caching.