Go’s promise has always been simple: write the code, compile, ship the binary, run it. The runtime is the OS. The OS is Linux. The binary is a single file. So why does Go hosting still feel like a small adventure every time you set it up?
Most platforms were built for Node, Python, or Ruby. They assume you have a package.json or a requirements.txt, a build step that takes thirty seconds, and a runtime that wants memory. Go has none of those. It has a 12 MB binary that starts in 40 milliseconds and uses 8 MB of RAM at idle. The platforms work with Go, but they charge for things you do not use and miss the things you do.
Table of contents
- Table of contents
- The direct answer
- What Go hosting actually needs
- The five Go hosting shapes in 2026
- The honest comparison
- The pricing trap most teams miss
- What to look for in a Go host
- FAQ
The direct answer
Go hosting works on almost any platform that runs Linux containers. The platform needs to (1) run a Docker image or extract a static binary, (2) forward port 80/443 to the port your binary listens on, and (3) keep the process running. That is the entire list. Everything else — build caching, deploy automation, environment variables, logs, health checks — is the same as any other language. The interesting question is which platform does that for the least money, and which one is the least painful when traffic spikes.
What Go hosting actually needs
The Go runtime story is unusual. Unlike Node (which needs a runtime) or Python (which needs an interpreter), Go compiles to a single binary that includes the runtime, the standard library, and your code. There are two flavors:
- CGO-enabled binaries. These need
glibcormuslon the target system. Most Docker images ship with one or the other. The binary is portable across distributions that match the libc. - CGO-disabled binaries (
CGO_ENABLED=0). These are fully static. They run on any Linux kernel, no glibc required. The image is the binary plus maybe a/etc/passwdand a/etc/resolv.conf. The whole container is often under 20 MB.
For hosting, the static binary is the dream. The image is 10 MB. The cold start is the time it takes to load the binary into memory. The memory footprint at idle is whatever you allocated, usually 8-30 MB for a simple HTTP service. A 256 MB container has 200+ MB of headroom for actual traffic.
What most platforms assume is that you want a Docker build. They run docker build, push to a registry, pull on the host, run the container. That is fine for Go, but it is overkill. The build step is go build -o app . and the result is a 12 MB file. Pushing a 12 MB binary to a registry and pulling it back is more network than the binary itself. A platform that supports direct binary deploys is faster and cheaper.
The five Go hosting shapes in 2026
There are five patterns you will encounter, and the differences are not subtle:
1. PaaS with native Go support. Platforms like Render, Railway, Fly.io, and RunxBuild’s Go service detect the go.mod file, run go build on every push, and serve the binary. You write a Procfile or a Dockerfile and the platform handles the rest. The deploy looks identical to a Node deploy from the dashboard’s perspective, but the runtime is just the binary.
2. Container PaaS. You bring a Dockerfile, the platform builds the image, runs it. Heroku, Render, Fly, AWS App Runner, and most “modern” platforms support this. The Docker layer is optional but the platforms prefer it because the abstraction is uniform across languages. For Go, this is the slowest and most expensive option, but it is the most flexible.
3. VM with systemd. You SSH in, copy the binary, set up a systemd unit, configure nginx as a reverse proxy, manage the certificate yourself. The cheapest at idle. The most painful at scale. The right answer for a single hobby project on a $5 VPS, the wrong answer for a SaaS that needs to scale.
4. Kubernetes with a custom controller. You build the image, push to a registry, write a Deployment manifest, set up a Service, configure an Ingress, manage cert-manager, set up HorizontalPodAutoscaler, and watch the platform do the work. The right answer for a team that has a platform engineer. The wrong answer for a solo founder.
5. Edge / serverless. Cloudflare Workers, Vercel Edge, Deno Deploy. Go support exists but it is not native. You compile to WASM and the runtime is the V8 sandbox or the Workers runtime. The cold start is fast, the latency is low, but you lose access to the standard library’s net package and most of the os package. Only the pure HTTP-handler parts of your code will run here. Most Go services are not pure HTTP handlers.
The honest comparison
For a typical Go HTTP service with 50,000 monthly requests and a 256 MB memory footprint:
| Platform | Idle cost | Realistic monthly | Cold start | Notes |
|---|---|---|---|---|
| Render (Starter) | $7/mo | $7-15/mo | ~1-2s | Easy, predictable |
| Fly.io (shared-1x) | $0-2/mo | $5-15/mo | <500ms | Best for Go specifically |
| Railway (Hobby) | $5/mo + usage | $8-20/mo | <500ms | Generous free trial |
| AWS App Runner | $5/mo + usage | $10-30/mo | 1-3s | AWS integration |
| Heroku (Eco dyno) | $5/mo | $5-12/mo | 2-5s | Old reliable |
| RunxBuild Go service | $0 idle | $3-8/mo | <300ms | Static binary, no per-request |
| Self-managed VPS | $5/mo | $5/mo + your time | 0s | You own everything |
The numbers are illustrative, not quoted — your actual cost depends on memory, CPU, and outbound bandwidth. The interesting column is “cold start.” Go is supposed to have near-zero cold start. A platform that imposes a 3-second cold start is wasting the binary’s main advantage.
The pricing trap most teams miss
Most “serverless” or “edge” platforms charge per request, per GB-second, or per invocation. Go services are efficient, so the per-request cost is small in absolute terms. It adds up. A 50,000-request-per-day Go service at $0.20 per million requests is $0.30/month for compute, which is fine. The same service on a flat-fee platform at $5/month is more expensive in absolute terms but the cost is predictable.
The trap is when traffic spikes. A 10x traffic spike on a per-request platform costs 10x. A 10x traffic spike on a flat-fee platform costs the same. For a Go service with no memory leaks and a clean build, a flat-fee platform is usually the cheaper long-term answer. The RunxBuild hosting calculator lets you model the steady-state cost against your current per-request bill.
The other trap is the build cost. Platforms that build Docker images on every push are charging you for the build minutes, the storage, and the network transfer of the image. For Go, where the build is go build and the artifact is 12 MB, the Docker layer is overhead you do not need. A platform that supports go install or a direct binary deploy avoids the overhead.
What to look for in a Go host
Five concrete things to check before you commit:
- Cold start time. Run a
curlagainst the deployed service after 5 minutes of idle. If the response time is over 1 second for a “hello world” Go service, the platform is doing something wrong. - Build cache. Go’s build cache is aggressive. A platform that throws it away on every push is making your deploys slow and your bill high. Look for platforms that cache the Go module cache and the build cache between deploys.
- Direct binary support. If the platform supports
go buildand serves the binary directly (without a Docker layer), your deploys are faster and your bills are smaller. The RunxBuild Go service supports this pattern. - Health check latency. A Go service that responds to a health check in under 5 ms is normal. A platform that takes 200 ms to call the health check is adding noise to your load balancer’s view of the world.
- Logs and metrics. The Go runtime is silent unless something is wrong. A platform that captures stdout and stderr, and exposes them as a log stream, is what you want. A platform that requires you to ship logs to a third party is asking you to do work the platform should do.
FAQ
Does Go need a special hosting platform?
No. Go compiles to a Linux binary, and any platform that runs Linux containers or binaries works. The question is which platform makes the Go-specific advantages (small binary, fast cold start, low memory) part of the pricing model instead of overhead you pay for.
Can I deploy a Go binary without Docker?
Yes. A static Go binary (built with CGO_ENABLED=0) runs on any Linux host. Some platforms accept a direct binary upload, others expect a Dockerfile. The direct path is faster but less portable.
What is the cheapest way to host a Go service?
For hobby projects, a $5 VPS with a systemd unit. For production services with predictable traffic, a flat-fee managed platform is usually cheaper than a per-request serverless option. The RunxBuild hosting calculator shows what the steady-state cost looks like.
Why is the cold start so slow on some Go platforms?
The platform is running the binary inside a Docker container, and the container’s startup time is the bottleneck. A native binary deploy (no container) has a cold start measured in tens of milliseconds. A container-wrapped binary has a cold start measured in hundreds of milliseconds to a few seconds, depending on the platform.
Should I use CGO for a Go service?
Almost never for a hosted service. CGO ties the binary to a specific libc version, which makes the Docker image larger and the deploy less portable. CGO_ENABLED=0 is the right default for HTTP services. The only reason to use CGO is if you need a C library (libxml, libsqlite, etc.) and there is no pure-Go alternative.
Can I run Go on Cloudflare Workers or Vercel Edge?
Yes, but with caveats. You compile to WASM and the runtime is the sandbox, not the Go runtime. The standard library is restricted, and you lose access to most OS-level features. Pure HTTP-handler code works. Anything that opens a file, a socket, or a subprocess does not.
What is the best free Go hosting in 2026?
For prototypes, Fly.io’s free tier covers small services, and Render’s free tier covers static sites. For production, none of the “free” tiers are reliable enough to depend on. The cheapest paid option for a real service is usually a flat-fee managed platform.
How does Go hosting compare to Node hosting?
Go hosting is cheaper in memory and faster in cold start, but the platforms are usually the same and the price is usually the same. The difference shows up at scale, when a Go service uses one-fifth the memory of an equivalent Node service and the platform’s per-GB pricing becomes a 5x advantage.