5 Min. Lesezeit
Wer auf Cloudflare Workers gebaut hat, kennt die Wand: ab dem Moment, wo der Code mehr als 128 MB RAM oder eine echte Linux-Toolchain braucht, wird das Deployment hässlich. Mit Containers GA seit dem 13. April 2026 verschiebt Cloudflare diese Wand. Web-Devs, die bisher zu EC2, Fly.io oder Render ausgewichen sind, bekommen einen Edge-Layer dazwischen, ohne Kubernetes-Cluster und ohne Datacenter-Vertrag.
10.05.2026
Das Wichtigste in Kürze
- Active-CPU-Pricing als echter Hebel: Containers werden nur abgerechnet, wenn die CPU tatsächlich Zyklen verbrennt. Idle-Container kosten nur Memory plus Storage, nicht Compute. Für Burst-Workloads ist das ein anderer Preisrahmen als bei AWS Fargate oder Fly.io.
- Hostnames, Docker Hub, SSH: Workers sprechen Container über Service-Bindings an, Images kommen aus Docker Hub oder einer Registry, SSH funktioniert für Live-Debugging. Der Stack fühlt sich nach klassischem Linux an, nicht nach Edge-Sandbox.
- Lücke zwischen Workers und EC2: Für Headless-Browser, ffmpeg, Pandoc oder kleine Inferenz-Endpoints war Workers bisher zu klein und EC2 zu schwer. Containers füllen genau diese mittlere Schicht und reduzieren den Stack-Sprung zu einem einzigen Anbieter.
Verwandt:Mini-PCs verdrängen 1HE-Server: Edge im RZ 2026 / Cloudflare Containers Dokumentation
Was Containers GA wirklich mitbringt
Was ist ein Cloudflare Container? Ein Cloudflare Container ist ein kurzlebiger Linux-Container, die im Cloudflare-Edge-Netz läuft und von einem Worker über Service-Bindings angesprochen wird. Er liegt funktional zwischen einer Workers-Function und einer klassischen Cloud-VM und deckt Workloads ab, die mehr Laufzeit, mehr Speicher oder eine vollständige Linux-Toolchain brauchen.
Die GA-Version bringt drei harte Verbesserungen gegenüber der Public Beta. Active-CPU-Pricing rechnet nur die tatsächlich verbrauchten CPU-Zyklen ab, nicht die Wall-Clock-Zeit. Limits liegen bei Tausenden parallel laufenden Containern pro Account. Service-Bindings adressieren Container per Hostname statt per IP, was DNS-Logik und Discovery-Code aus dem Worker rausnimmt.
Dazu kommen Docker-Hub-Support für direkte Image-Pulls, SSH für Live-Debugging und Sandboxes als Schwester-Produkt für AI-Agent-Workloads mit persistenten Filesystem-Sessions. Wer einen Worker hat, der einen Headless-Browser für Screenshots oder eine Pandoc-Pipeline für PDFs braucht, ruft jetzt einen Container über Service-Binding auf, statt einen externen API-Anbieter dazwischenzuschalten.
Wo der Edge-Vorteil greift, wo nicht
Containers laufen nicht in jeder Edge-Location, sondern werden bei Bedarf in der nächstgelegenen verfügbaren Region gestartet. Für interaktive Web-Apps mit DACH-Nutzern bedeutet das in der Regel Frankfurt oder Düsseldorf. Latenzen zwischen Worker und Container liegen damit im einstelligen Millisekunden-Bereich, der Sprung zu einem klassischen Backend in Frankfurt oder Dublin entfällt. Die offizielle Plattform-Dokumentation listet die unterstützten Regionen und Limits explizit auf.
Wo das wirklich beißt, ist das Bild- und PDF-Processing. Ein Worker, der einen Container mit ImageMagick aufruft, spart sich einen Hop zu einem Lambda oder einem Render-Service plus dessen Cold-Start. Ähnlich für Headless-Browser-Workloads: Playwright in einem Container neben dem Worker liefert Screenshots in 700 bis 1.200 ms Total-Latency, wo der Umweg über einen externen Browserless-Endpoint oft das Doppelte braucht.
Was Containers nicht ersetzen, sind Long-Running-Services mit eigenem State. Eine Postgres-Instanz gehört nach wie vor in eine Datenbank-Plattform, ein Kafka-Broker auf eine VM. Containers sind kurzlebig, werden bei Inaktivität heruntergefahren und starten kalt neu. Wer das nicht im Kopf hat, baut Architekturen, die in der Rechnung am Monatsende überraschen.
Workers, Containers, EC2: was wann
Wann Containers passen
- Headless-Browser, Pandoc, ffmpeg, Tesseract neben einem Worker
- Kleine Inferenz-Endpoints, die nicht in eine Workers-AI-Funktion passen
- CLI-Tools, die ein vollständiges Linux brauchen
- Burst-Workloads mit langen Idle-Phasen, dank Active-CPU-Pricing
Wann nicht
- Datenbanken oder andere Long-Running-Services mit lokalem State
- Workloads, die feste Region-Garantien brauchen (Compliance)
- GPU-Inferenz für große Modelle, hier bleibt Workers AI oder ein Hyperscaler
- Bestandsstacks, die schon auf Kubernetes laufen und konsolidiert sind
Ein 60-Tage-Plan für DACH-Teams
Wer den Stack ernsthaft prüfen will, fängt nicht mit einer Migration an, sondern mit einem konkreten Workload, der heute weh tut.
Häufige Fragen
Brauche ich für Containers einen kostenpflichtigen Cloudflare-Plan?
Ja, Containers laufen auf dem Workers Paid Plan, der bei 5 US-Dollar pro Monat startet. Active-CPU-Pricing kommt obendrauf, abgerechnet wird Sekunden-genau. Für reine Tests reicht der Paid Plan, für produktive Setups mit hoher Last lohnt sich Workers Enterprise wegen besserer Limits und Support-SLAs.
Kann ich meine bestehenden Docker-Images direkt nutzen?
In den meisten Fällen ja. Cloudflare unterstützt Docker-Hub-Pulls und private Registries, Image-Größen bis mehrere Gigabyte sind machbar. Was nicht funktioniert sind Images, die auf Privileged-Mode oder spezielle Kernel-Module setzen und Workloads mit GPU-Anforderungen jenseits dessen, was Cloudflare-Container heute bieten.
Wie verhält sich der Stack zu DSGVO und Datenresidenz?
Cloudflare bietet Region-Affinity-Optionen, mit denen Container in EU-Standorten gepinnt werden können. Wer harte Datenresidenz braucht (öffentlicher Sektor, Banken), prüft die Enterprise-Konfiguration und holt eine schriftliche Zusicherung. Standard-Setups landen pragmatisch in Frankfurt oder Amsterdam, was für die meisten DACH-Workloads ausreicht.
Über den Autor
Adrian Garcia-Kunz ist Web Developer bei Evernine. Er kommt aus dem Frontend-Stack, kennt aber den Punkt, an dem ein Worker oder eine Lambda nicht mehr reicht. Er hält wenig von Stack-Modetheater und viel von Tools, die in sechs Monaten noch laufen.
Mehr aus dem MBF Media Netzwerk
Bildquelle: KI-generiert (Mai 2026), C2PA-Zertifikat im Bild hinterlegt
