Down-to-Zero (DTZ) has always been about doing more with fewer watts and fewer bytes. From scale-to-zero container scheduling to solar-powered build runners, every service we ship is measured against a ruthless baseline: could this run happily on a fan-less notebook CPU in the sun?
Today we are excited to announce the next step on that journey - remote Model Context Protocol (MCP) servers that you can spin up as lightweight Docker containers inside any DTZ context.
MCP is an open standard that lets language-model hosts reach out to task-specific “servers” for data, tools, or actions, using a simple, authenticated JSON stream. Think of it as a USB-C port for AI agents: one plug, many peripherals. By running an MCP server next to your data, you avoid shuttling entire datasets through an LLM API call. That fits perfectly with our “shift computation to the edge, not the core” mantra.
Until now DTZ’s multi-tenant load balancer terminated only HTTP/1 and HTTP/2. MCP, however, relies on Server-Sent Events (SSE) for its long-lived, one-way event stream. SSE works great over HTTP/2, but browsers strictly limit concurrent SSE connections when they fall back to HTTP/1 — usually six per origin.
We have therefore extended the balancer with native SSE support:
This improvement unlocks remote-first MCP servers: you can now deploy the server component as a container image and have any LLM client connect back through secure SSE without extra proxies.
Build (or download) an MCP server image.
Push it to your private DTZ registry:
docker push {context-id}.cr.dtz.dev/my-mcp-server:latest
Create a new service in your context and point it at the image. Our scheduler pulls only on demand and scales to zero when no host is connected.
Because the registry endpoint lives inside the same energy-efficient mesh, image pulls happen over the local backbone, keeping egress near zero and speeding up cold starts.
Remote MCP servers typically need a single Rust- or Go-based binary plus a tiny Alpine base layer. In our own tests a full-featured GitHub integration server consumes 15 MiB RAM at boot and idles below 2 W on our DTZ worker nodes. That leaves plenty of headroom for dozens of servers per node before the solar panels even notice.
For workloads that do spike, DTZ’s cgroup isolation lets the kernel reclaim memory the moment the job is done. Combined with the balancer’s SSE hibernation, your context returns to zero just seconds after the last token is streamed to your model.
We are actively integrating the DTZ Identity Server via OAuth 2.1 into the MCP ecosystem, ensuring that every stream is served only to authenticated clients and your remote servers remain both minimal and secure.
Less energy, less fuss - just context where you need it.