app.nzapp
AppsProjectsReposPullsChatIntegrationsGatewayModelsEvalsToolsDatasetsMCPDeploysPricingBlogDocsAssistantsCharactersArtMusic
Sign inStart building
Agent stack
Cloud coding agentAgents SDKIntegrationsBrowser agentMonitors & auto-agentsSchedulersAgent skillsMCP serversDeep research
Models & API
AI GatewayModel catalogModel evalsModel spacesPlaygroundText to imageImage to 3DText to 3DMusic & SFXAudio editorMedia optimizerAI art & libraryChatAPI referenceSchemaBecome a provider
Compute & hosting
DeploysAddonsPostgres hostinggobed vector searchSite hostingAnalyticsCog GPU hostingRL trainingBuilds & CIWorkersTask queuesDomainsGit hosting
Tools
AI toolsDrawDiffusion canvasLive DrawWriteSheetsArtifactsVideo studioNotebooksDatasets
Learn
DocsBlogEval guidesPrompt libraryCLIAlternativesPapersAI charactersArt gallerySecurityConsulting
Company
PricingEnterpriseSettingsBillingStatusInvestorsCreate accountTerms of ServicePrivacy Policy
app.nzapp.nz

AI agent cloud for coding, deploys, model routing, and research. Built for teams shipping software.

Built in New Zealand by App AI NZ.

Social
X / TwitterGitHubYouTube
The app.nz network
GpuBrainPapersReading TimeNetwrckText-Generator.ioCodex InfinityOpenPathsCuteDSLAI Art GeneratorAIArt-Generator.artSiteSimSimplexGenDictatorFlowWebFiddleRing.nzChatGibidyBitBankExperimentFlowEvangelerHires.nzHow.nzV5 GamesAddicting Word GamesBig Multiplayer ChessWord SmashingreWord GameMultiplication Master
© 2026 App AI NZ Ltd. All rights reserved.All systems normalTermsPrivacy
Blog
July 15, 2026·8 min read·Lee Penkman

Inside the polyserve Go host: fasthttp, unix-socket slots, and zero-drop hot swaps

How one fasthttp process serves many compiled Go apps with microsecond proxy overhead, atomic generation swaps with a 5s drain, and Postgres addons via injected DATABASE_URL.

polyserve serves many apps ("spaces") from one long-lived host process per language. This post is about the Go host: how one fasthttp front serves hundreds of compiled Go binaries with microsecond-level proxy overhead, and how deploys swap a running binary without dropping a request. If you have not read the announcement, start there.

Architecture: one fasthttp front, N binaries

The host is a single fasthttp server (default port 8440). Your app is a normal compiled Go binary — net/http, zero polyserve dependencies — that the host runs behind a unix socket. Requests arrive at the host as /s/<owner>/<name>/<rest> (or by Host header for mapped custom domains, resolved from the host's spaces.json state file) and are proxied to the space's socket with path /<rest>.

Why unix sockets? No TCP handshake, no port allocation, kernel-local transfer — the proxy hop costs microseconds, not the milliseconds of a network hop to a sidecar or gateway. For spaces that want to eliminate even that, the host can load a .so plugin fully in-process instead.

Deploying is one curl

Straight from the README — build for linux, POST the binary:

GOOS=linux go build -o hello ./examples/go-hello
curl -X POST localhost:8440/_polyserve/deploy -F space=lee101/hello -F binary=@hello
curl localhost:8440/s/lee101/hello/

The deploy endpoint responds with the new generation:

{"ok":true,"space":"lee101/hello","generation":N}

If POLYSERVE_ADMIN_TOKEN is set, control endpoints require Authorization: Bearer <token>.

Hot swap: generation slots and a 5s drain

Each deploy of a space is a generation. On POST /_polyserve/deploy the host:

  1. Saves the uploaded executable to slots/<owner>/<name>/bin-<N>
  2. Starts the new process on a fresh unix socket
  3. Atomically switches traffic to the new socket
  4. Drains the old process for 5 seconds, then kills it

In-flight requests on the old generation finish during the drain; new requests already go to the new one. Zero dropped requests, no load balancer choreography, no rolling-update machinery — it is a pointer swap inside one process.

Scale-to-zero and cold starts

A space idle past POLYSERVE_IDLE_TTL (default 900s) has its process stopped. The binary and its state entry stay on disk, so the next request cold-starts it transparently — the budget for a Go binary is under 100ms, which is why scale-to-zero is on by default rather than an enterprise checkbox.

Metering for free

Because the host proxies every request, it meters every request. GET /_polyserve/usage returns monotonic per-space counters:

{"spaces":{"lee101/hello":{"requests":123,"busy_ms":4567,"warm_s":890,"loaded":true}}}

busy_ms is cumulative wall time with at least one in-flight request (billable compute); warm_s is cumulative seconds loaded in memory (billable residency). The control plane diffs between scrapes, and the host appends usage once per minute to usage.jsonl so billing survives crashes.

Postgres addons via injected DATABASE_URL

Spaces receive per-space environment through the deploy call: env is a repeatable KEY=VALUE field. On app.nz the control plane provisions the Postgres addon and passes credentials at deploy time; the examples/go-postgres example is an ordinary Go app reading DATABASE_URL. Locally:

GOOS=linux go build -o pgapp ./examples/go-postgres
curl -X POST localhost:8440/_polyserve/deploy \
  -F space=lee101/pgapp \
  -F binary=@pgapp \
  -F env=DATABASE_URL=postgres://user:pass@host:5432/db

Removing a space is symmetric: DELETE /_polyserve/spaces/<owner>/<name> unloads and removes it.

Where this fits

The same protocol powers the Python and Bun hosts — the Python host is what makes in-process ONNX serving work — and one tiny autoscaler loop adds or removes Hetzner and RunPod workers from aggregate usage. Full per-language quickstarts are in the deploy docs. Source: github.com/lee101/polyserve, mirrored at app.nz/lee101/polyserve.

Build what you just read

Ship agents, models, and apps on one cloud.

Start with free credits, then use the same platform from the web app, CLI, desktop app, or MCP.

Start building freeRead the docs

Keep reading

polyserve: in-process serverless that packs hundreds of apps into one process

Announcing polyserve, the open-source in-process serverless host behind app.nz: per-second billing via busy_ms and warm_s, hot-swap deploys, scale-to-zero, and autoscaling to Hetzner and RunPod GPUs.

polyserve deploy docs: Go, Python, and Bun quickstarts

Per-language deploy quickstarts for polyserve spaces plus the full host control protocol: deploy, usage, health, routing, scale-to-zero, env vars, addons, and the autoscaler contract.

Serving tiny ONNX models serverlessly, in-process

Why in-process beats a dedicated model server for small ONNX models: warm sessions in one asyncio host, sub-500ms cold starts, honest per-second metering, and RunPod GPU autoscaling for bigger models.