Down-to-Zero (DTZ) ging schon immer darum, mehr mit weniger Watt und weniger Bytes zu erreichen. Vom Scale-to-Zero-Container-Scheduling bis hin zu solarbetriebenen Build-Runnern wird jeder Dienst, den wir ausliefern, an einer unerbittlichen Messlatte geprüft: könnte das glücklich auf einer lüfterlosen Notebook-CPU in der Sonne laufen?
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 ist ein offener Standard, der es Language-Model-Hosts ermöglicht, per einfachem, authentifiziertem JSON-Stream task-spezifische „Server“ für Daten, Werkzeuge oder Aktionen anzusprechen. Denk daran wie an einen USB-C-Anschluss für KI-Agenten: ein Stecker, viele Peripherien. Wenn du einen MCP-Server neben deinen Daten betreibst, vermeidest du das Hin- und Herschaufeln ganzer Datensätze durch einen LLM-API-Aufruf. Das passt perfekt zu unserem Mantra „shift computation to the edge, not the core“.
Bis jetzt terminierte DTZs multi-tenant Load-Balancer nur HTTP/1 und HTTP/2. MCP setzt jedoch auf Server-Sent Events (SSE) für seinen langlebigen, unidirektionalen Event-Stream. SSE funktioniert hervorragend über HTTP/2, aber Browser begrenzen strikt gleichzeitig offene SSE-Verbindungen, wenn sie auf HTTP/1 zurückfallen — üblicherweise sechs pro Origin.
Wir haben den Balancer daher um native SSE-Unterstützung erweitert:
Diese Verbesserung öffnet den Weg für remote-first MCP-Server: Du kannst die Serverkomponente jetzt als Container-Image bereitstellen und jeden LLM-Client sicher per SSE verbinden lassen, ganz ohne zusätzliche Proxys.
Build (oder lade herunter) ein MCP-Server-Image.
Push es in dein privates DTZ-Registry:
docker push {context-id}.cr.dtz.dev/my-mcp-server:latest
Erstelle einen neuen service in deinem Kontext und verweise ihn auf das Image. Unser Scheduler zieht nur bei Bedarf und skaliert auf null, wenn kein Host verbunden ist.
Weil der Registry-Endpunkt im selben energieeffizienten Mesh liegt, erfolgen Image-Pulls über das lokale Backbone, halten den ausgehenden Datenverkehr nahe null und beschleunigen Cold Starts.
Remote-MCP-Server benötigen typischerweise nur ein einzelnes Rust- oder Go-basiertes Binary plus eine winzige Alpine-Basis-Schicht. In unseren eigenen Tests verbraucht ein voll ausgestatteter GitHub-Integrations-Server 15 MiB RAM beim Booten und idlet unter 2 W auf unseren DTZ-Worker-Nodes. Das lässt reichlich Spielraum für Dutzende Server pro Node, bevor die Solarpanels überhaupt reagieren.
Für Workloads, die wirklich ansteigen, erlaubt DTZs cgroup-Isolation dem Kernel, Speicher sofort zurückzufordern, sobald der Job abgeschlossen ist. Kombiniert mit der SSE-Hibernation des Balancers kehrt dein Kontext nur Sekunden nach dem letzten an dein Modell gestreamten Token wieder auf null zurück.
Wir integrieren aktiv den DTZ Identity Server via OAuth 2.1 in das MCP-Ökosystem, um sicherzustellen, dass jeder Stream ausschließlich an authentifizierte Clients ausgeliefert wird und deine Remote-Server sowohl minimal als auch sicher bleiben.
Weniger Energie, weniger Tamtam — einfach Kontext, wo du ihn brauchst.