Guide
Rolling deployment for Go
A rolling deploy replaces instances one at a time. Capacity stays up throughout, and no replica joins the proxy until it passes its health check.
How a replica is replaced
Each replacement starts on a fresh internal port alongside the instance it replaces. It joins the proxy only after passing its health check, and the old instance is then drained from rotation and stopped.
Because old and new instances coexist during each step, the rollout never routes a request to a dead port. Passing a smaller replica count shrinks the deployment by draining the surplus replicas at the end.
Rolling versus blue-green
Blue-green runs two full slots and switches all traffic at once, so a bad candidate is visible immediately and rollback is one switch. Rolling keeps multiple replicas of each version and moves gradually, which suits services that already run more than one instance.
Both require the proxy and a zero-downtime strategy; classic deploy remains a stop-then-start and can drop traffic briefly.
Health, then traffic
The health tier decides when a replacement is safe. An explicit HTTP readiness path is best; a TCP or PID check proves far less. Repeated endpoint failures after deploy can trigger bounded restart attempts, and an instance that cannot be restored is recorded as degraded rather than restarted forever.
Frequently asked questions
Short answers; the docs go deeper.
What is a rolling deployment for a Go service?
Replacing running instances one at a time. Each new replica starts beside the one it replaces, passes its health check, joins the proxy, and only then is the old replica drained and stopped.
How many replicas does a rolling deploy use?
You choose with --replicas N. A smaller count than the current deployment drains the surplus replicas at the end of the rollout.
One binary between git push and production.
Install the CLI, verify the host, and follow the quick start to build your first application.