Back to blog
EngineeringMarch 19, 2026

Building a 15 MB deployment agent in Go

The Glinr agent runs on any VPS with no runtime dependencies. Here's how we kept the binary small, the memory footprint lean, and the WebSocket connection rock-solid.

The Glinr agent is a single static binary that runs on any Linux VPS — no Docker image to pull, no Node.js runtime, no Python interpreter. You download it, run it with your API key, and your server appears in the dashboard within seconds. The binary is 15 MB compressed and uses around 18 MB of RSS at idle. Here's how we got there.

Why Go, and why a single binary

The alternative was a Node.js agent or a Python agent. Both have runtimes that need to be installed and kept up to date. Both have `node_modules` or virtual environments that vary between systems. Both add operational complexity for users who just want to connect their server. Go compiles to a single statically-linked binary with no external dependencies beyond `libc` on Linux. CGO disabled, `GOOS=linux GOARCH=amd64`, and you get a file you can `scp` to any machine and run immediately.

CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build \
  -ldflags "-s -w" \
  -o glinr-agent \
  ./cmd/agent

The `-ldflags "-s -w"` strips the symbol table and DWARF debug information, which shaves several megabytes off the final binary. We also use `upx --best` in the release pipeline to compress the binary further. The tradeoff is a slightly slower startup — about 300ms — which is acceptable for a long-running daemon that restarts infrequently.

The WebSocket connection

The agent maintains a persistent WebSocket connection to the Glinr API. When the connection drops — due to a network hiccup, a deploy, or a server restart — it reconnects with exponential backoff starting at one second and capping at 30 seconds. We use a ping/pong heartbeat every 15 seconds to detect zombie connections before the OS-level TCP keepalive would kick in. The result is a connection that survives NAT timeouts, brief network interruptions, and API restarts without losing any queued commands.

All Docker operations go through the Docker SDK with context-aware timeouts. A build that takes more than 20 minutes is cancelled automatically. Container resource limits — CPU shares, memory, and PID limits — are set on every container at creation time. We never pass `--privileged`. The agent itself runs as a non-root user where possible, and we document how to configure it with the minimal required permissions for Docker socket access.