Every tool in the lab ships the same way: one Go binary. The identity server is one static binary and a Postgres database. The terminal agent is a single binary. Even the reader app carries its web frontend inside itself. This is a note about why I keep choosing that, and what it costs.
Deploying becomes a copy
When the whole program is one file, a deploy is a file copy and a restart. There is no runtime to install, no dependency tree to resolve on the server, and no “works on my machine” gap to debug at the worst moment.
- Nothing to install on the target machine
- The version you tested is the version that runs
- Rolling back is copying the previous file back
The best deployment guide is the one you never have to write.
The frontend rides inside
Go can embed a folder of files into the binary at build time. Build the web app, point the embed directive at the output, and the server hands those files out itself.
// the built web app, carried inside the binary
//go:embed all:dist
var assets embed.FS
What it costs
It is not free. Binaries are bigger than scripts, rebuilds take a moment, and there is no editing a live file in a panic. I have decided those are good trades. Your answer might differ, and that is fine.
Where to start
Pick your smallest internal tool and ship it as one file. Notice how little there is to write down about running it. That is the feeling worth chasing.