Go Binary Deployment
Fast recall
Quick revision
Core answer
Whether you understand Go Binary Deployment beyond memorized syntax.
Giving a definition without explaining a practical trade-off.
Connect the concept to a small production example and state its complexity or failure mode.
Interview-ready guide
Interview answer
The build-and-deploy:
# Build the static binary
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o myapp .
# -s -w: strip debug info — smaller binary
# Copy to the server
scp myapp user@server:/opt/myapp/myapp
# The systemd unit (/etc/systemd/system/myapp.service)
[Unit]
Description=My Go App
After=network.target
[Service]
ExecStart=/opt/myapp/myapp
Environment=PORT=8080
Restart=always
User=app
[Install]
WantedBy=multi-user.target
# Enable and start
sudo systemctl daemon-reload
sudo systemctl enable --now myapp
sudo systemctl status myapp
journalctl -u myapp -f # the logsThe Go advantage this question tests: the binary is a single static file — no JVM, no Python interpreter, no node_modules, no runtime dependencies to install on the target. Copy one file, run one process. This is Go's deployment story.
The systemd features (the production requirements): Restart=always (crash → automatic restart — the resilient process); Environment (the config); User (the non-root security); After=network.target (the dependency ordering); journalctl (the log integration).
The binary's self-sufficiency: CGO_ENABLED=0 → no libc — runs on ANY Linux (distro, version); the Go runtime and the net stack are linked in. The 15MB single file is the entire deployment artifact.
The upgrade path (the production dance): build the new binary → scp it as myapp.new → the health check → mv myapp.new myapp → systemctl restart myapp — a brief downtime; the zero-downtime version (the socket handoff) or the blue-green (two instances behind a LB) are the scale-up.
Go Binary Deployment
Direct Answer
go build → the static binary (CGO_ENABLED=0) → scp to the server → systemd unit (Restart=always) or a process manager. The binary is self-contained: no runtime, no dependencies.
Deep Dive & Architecture
The systemd unit's production tuning (the interview's depth layer): RestartSec=5 (the backoff between restarts — a crash-loop at 0 delay is a CPU burner); LimitNOFILE (the file descriptors — a Go server with many connections); WorkingDirectory (relative paths); Environment= or EnvironmentFile=/opt/myapp/env (the config file — the secret separation).
The zero-downtime graceful handoff (Go's specific capability): the new process inherits the listening socket (systemd's FD passing or the SO_REUSEPORT trick), the old process stops accepting, finishes in-flight, exits. Go's http.Server.Shutdown + the socket-inheritance is the deployment story without a load balancer.
The binary-vs-container decision, honestly: the binary alone (the scp+systemd path) is Go's heritage deployment — smallest, simplest, the single-artifact advantage. The container adds: the same artifact everywhere (the image layers include the runtime environment: certs, timezone), the orchestrator's lifecycle (Kubernetes' health probes, rolling updates), and the standardized pipeline. The modern default is the container; the bare binary remains the fall-back and the proof of Go's self-containment.
Common Mistakes & Pitfalls
Giving a definition without explaining a practical trade-off.
Check your understanding
Answer these without looking back at the article.
- When would you use Go Binary Deployment in a real project?
- How would you compare Go Binary Deployment with an alternative?
- What is a common mistake when using Go Binary Deployment?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.