Go 1.22 serverless functions in isolated containers
Deploy Go 1.22 functions as isolated serverless containers: familiar net/http handler patterns, full Go module ecosystem including CGO-dependent packages, goroutine-safe concurrency model, and gateway routing shared with Node.js and Python functions in the same workspace.
Last updated: 2026-04-20
Answer first
Direct answer
Go 1.22 serverless functions in isolated containers. Inquir Go functions use standard net/http handler patterns—the same code you write locally runs in production. CGO packages work because functions run in full Docker-based containers with a real Linux environment.
When it fits
- High-throughput JSON API handlers where Go allocation efficiency matters
- Functions that depend on CGO packages (SQLite, image processing, crypto)
- Teams already writing Go services who want consistent language across the stack
Tradeoffs
- Edge runtimes run in V8 isolates—no CGO, no native modules, no system packages. SQLite bindings, image processing libraries, and crypto packages that depend on C are simply not available.
- Lambda Go runtime requires compiling a main binary with a custom handler signature—not standard net/http—and wrapping it in a bootstrap. Every function is a separate deployment artifact.
Workload and what breaks
Why Go serverless was painful before
- Edge isolates do not support CGO or native system libraries
- AWS Lambda Go runtime requires a custom bootstrap binary per function
- Mixing Go functions with Node.js or Python APIs meant separate platforms or Lambda layers hacks
Go is ideal for high-throughput HTTP handlers, CLI tools compiled into functions, and computationally heavy work that benefits from static typing and goroutines. But standard serverless platforms treat Go as a second-class citizen—requiring bootstrap wrappers, excluding CGO, or forcing you off the platform entirely.
Trade-offs
What you lose on edge or Lambda Go runtimes
Edge runtimes run in V8 isolates—no CGO, no native modules, no system packages. SQLite bindings, image processing libraries, and crypto packages that depend on C are simply not available.
Lambda Go runtime requires compiling a main binary with a custom handler signature—not standard net/http—and wrapping it in a bootstrap. Every function is a separate deployment artifact.
How Inquir helps
Standard net/http handlers in isolated containers
Inquir Go functions use standard net/http handler patterns—the same code you write locally runs in production. CGO packages work because functions run in full Docker-based containers with a real Linux environment.
Go functions share the API gateway with Node.js and Python functions in the same workspace. One routing table, one secrets model, one observability stack—regardless of language.
What you get
Go 1.22 serverless function features
Standard net/http handlers
Write func(w http.ResponseWriter, r *http.Request) and deploy. No custom runtime wrappers or bootstrap binaries.
Full Go module ecosystem
go.mod and go.sum included. CGO-dependent packages like mattn/go-sqlite3 work in container builds.
Goroutine-safe concurrency
Go goroutines work as expected. Fan out concurrent requests, use channels, and leverage Go native concurrency primitives.
Polyglot workspace
Go functions share gateway routes, secrets, and observability with Node.js and Python functions in the same workspace.
What to do next
How to deploy Go serverless functions on Inquir
Write a net/http handler
Standard Go HTTP handler. Import net/http, no custom runtime package required.
Define go.mod
Standard Go module file. List dependencies including CGO packages if needed.
Deploy and route
Inquir builds the container, deploys the function, and adds it to gateway routing alongside other language functions.
Code example
Go serverless function: fast JSON API handler
Standard net/http pattern. Reads from environment, returns JSON. CGO dependencies work in the container build.
package main import ( "encoding/json" "net/http" "os" ) type Response struct { Status string `json:"status"` Version string `json:"version"` Region string `json:"region,omitempty"` } func Handler(w http.ResponseWriter, r *http.Request) { if r.Method != http.MethodGet { http.Error(w, "method not allowed", http.StatusMethodNotAllowed) return } resp := Response{ Status: "ok", Version: "1.0.0", Region: os.Getenv("INQUIR_REGION"), } w.Header().Set("Content-Type", "application/json") json.NewEncoder(w).Encode(resp) }
When it fits
Use Go serverless functions for
When this works
- High-throughput JSON API handlers where Go allocation efficiency matters
- Functions that depend on CGO packages (SQLite, image processing, crypto)
- Teams already writing Go services who want consistent language across the stack
When to skip it
- Heavy ML/data processing—Python with numpy/pandas is better suited for that use case
FAQ
FAQ
Does CGO work in Inquir Go functions?
Yes. Functions run in full Docker-based containers with a real Linux build environment—CGO packages build and run as expected, unlike edge runtimes.
Can I import packages from private Go module registries?
Yes—configure GONOSUMCHECK and GOMODCACHE settings via workspace secrets and build configuration. Private module credentials are injected at build time, not stored in source.
How does cold start compare to Node.js?
Go binaries typically start faster than Node.js for the same workload. Use hot containers for steady traffic patterns regardless of language for consistent p95 latency.