Go Hosting
for Compiled Binaries

Modern Go deployment leverages the language's strengths through containerization:

• Multi-Stage Builds: You compile your code in a golang container, then copy only the binary to a lightweight alpine or scratch image for production.
• App + Database Separation: Your Go binary is stateless. Data lives in a dedicated database service (PostgreSQL, MySQL) connected via TCP.
• Environment Variables: Configuration (DB credentials, API keys) is injected at runtime via os.Getenv(), keeping your binary generic and secure.
• Zero Dependencies: Because everything is linked into the binary, you don't have to worry about system library versions or "dependency hell" on the host.

• Turn cgo off. CGO_ENABLED=0 is what makes the binary static and lets it run in scratch or distroless. Leave it on and the image needs glibc, which those base images do not have — the container exits immediately with no such file or directory for a binary that is clearly there. The usual culprits are the standard net resolver and mattn/go-sqlite3; the first has a pure-Go path, the second does not.
• Bind to 0.0.0.0, not localhost. http.ListenAndServe(":8080", …) is already correct. 127.0.0.1:8080 is not reachable from outside the container.
• Handle SIGTERM. A deploy sends SIGTERM and waits 60 seconds before killing the container. Catch it with signal.NotifyContext and call server.Shutdown(ctx) so in-flight requests finish. Without it, Go exits on the signal by default and every open request drops on each deploy.
• Give it a health check path. Set one on the app and the platform probes it every 10 seconds with a 2-second timeout, marking the container unready after 3 failures. A handler that only returns 200 is enough; one that checks the database means a database blip takes the app out of rotation with it.

Nothing here is Hostim-specific — it is what any container runtime expects. Go just makes it visible, because there is no framework or process manager papering over it.

"Free" hosting usually comes with significant caveats. Providers offering free tiers often:

• Sleep or spin down your app after inactivity. While Go starts fast, the database connection pool often needs time to warm up.
• Limit CPU and RAM. Go is efficient, but a constrained environment can lead to OOM kills during garbage collection spikes.
• Lack persistent storage, meaning any files written to disk disappear on restart.

Free tiers are excellent for learning and prototypes but often break for real-world applications requiring reliability. Hostim.dev offers a preview tier for testing, but our focus is on reliable, paid production hosting with predictable pricing.