Why We Skipped Docker: Building Deployable Go Binaries in Minutes

In many past projects we used Docker with generally good results, but sometimes we encountered mysterious issues on Red Hat systems that were not necessarily Docker’s fault.

For this project we decided Docker was unnecessary. We wrote the web service and static HTML in Go, using Go 1.16’s //embed directive, producing a single deployable binary.

As a resource‑constrained startup we chose Go because it lets us build fast web services and scale easily; each server can handle thousands of requests per second, though our current load is under a thousand. We note that Node/Deno with V8 could achieve similar performance, and for low traffic the language choice matters little.

Go’s packaging is far simpler than Node, Java, or C#: the result is just one binary.

Build, test, and deployment commands are straightforward:

go build

go test

scp app user@host:
ssh user@host "nohup ./app"

In practice we added a SystemD unit to start the service on boot and a dedicated build server running a ten‑line shell script that performs git clone, go build, go test, go lint, and go vet. We may later add a UI such as Rundeck to control deployments.

The total time spent building and deploying was minimal, and we question how much effort is really required to learn, install, and troubleshoot Docker compared with using Go’s built‑in capabilities.

We invite readers to share their thoughts on Docker.