Cloudflare hat gerade Containers veröffentlicht: Hier ist alles, was du wissen musst
Jonas ScholzCloudflare Containers ermöglichen es dir, jedes Docker Image auf Cloudflares mehr als 300 Edge-Standorten laufen zu lassen. Du steuerst sie mit wenigen Zeilen JavaScript in einem Worker, sie skalieren auf null herunter und werden in 10-ms-Scheiben abgerechnet, während sie aktiv sind.
Sie füllen die Lücke zwischen:
| Modell | Stärken | Kompromisse |
|---|---|---|
| Workers (heute) | Start in Millisekunden, weltweit | Nur V8, 128 MB RAM |
| Always-on PaaS (z.B. sliplane) | Einfach, vorhersehbar | Du zahlst 24/7, auch im Leerlauf |
| DIY Kubernetes / Fargate | Volle Kontrolle bei Skalierung | Overhead durch Cluster, LB, IAM |
Cloudflare Containers bringen die Edge-Reichweite und das Pay-for-use-Preismodell von Workers zu Workloads, die eine vollständige Linux-Sandbox benötigen.
Warum sollte dich das interessieren?
- Native Binaries oder vollständiges Dateisystem, sodass du FFmpeg, Pandas oder AI-Toolchains ausführen kannst.
- Sprachen jenseits von JS oder Wasm, wie Go, Rust, Python, Java, Ruby oder alles, was dein Dockerfile enthält.
- Größere Ressourcen mit bis zu 4 GiB RAM und einer halben vCPU pro Instanz (größere Varianten sind geplant).
- Tenant-spezifischer Status mit einem Container pro Durable-Object-ID für sticky Sessions.
- Jobs mit hoher Auslastung in kurzen Zeiträumen wie Cron, Code-Auswertung oder Video-Export bei Bedarf.
Wenn dein Code viel im Leerlauf ist, ist das Skalieren auf null besser als für einen dauerhaft laufenden Container zu bezahlen (egal ob sliplane, ein VPS oder ein verwalteter Dyno).
Wie es funktioniert
# 1. Grundgerüst erstellen + deployen
npm create cloudflare@latest -- --template=cloudflare/templates/containers-template
wrangler deploy
// 2. Anfragen in deinem Worker routen
import { Container, getRandom } from "@cloudflare/containers";
class API extends Container {
defaultPort = 8080;
sleepAfter = "10m";
}
export default {
async fetch(req, env) {
const instance = getRandom(env.API, 3); // einfacher Round-Robin-Helper
return instance.fetch(req);
},
};
Der erste Aufruf ist ein Kaltstart (etwa 2 bis 3 Sekunden in der Beta). Danach bleibt der Container warm, bis er für die in sleepAfter festgelegte Dauer im Leerlauf ist.
Unter der Haube ist jeder Container mit einem Durable Object gekoppelt, das den Lebenszyklus und das Routing verwaltet. Es gibt kein YAML, keine Nodes, nur Code.
Preisübersicht
| Zähler (Workers Paid, $5/Monat) | Freies Kontingent | Überschreitungsrate |
|---|---|---|
| Speicher | 25 GiB-Stunden | $0,0000025 / GiB-s |
| CPU | 375 vCPU-Minuten | $0,000020 / vCPU-s |
| Festplatte | 200 GB-Stunden | $0,00000007 / GB-s |
Instanzgrößen in der Beta sind dev (256 MiB), basic (1 GiB) und standard (4 GiB). Größere Varianten sind in Arbeit.
Nehmen wir eine "standard" Instanz an (4 GiB RAM, halbe vCPU, 4 GB Festplatte), die 24×7 für einen 30-Tage-Monat läuft und 2 TB Traffic überträgt. Dies ist eine Workload, die besser für ein Always-on PaaS geeignet ist.
| Zähler | Rohnutzung | Freies Kontingent | Abrechenbar | Rate | Kosten |
|---|---|---|---|---|---|
| Speicher | 4 GiB × 2.592.000 s = 10.368.000 GiB-s | 25 GiB-h = 90.000 GiB-s | 10.278.000 GiB-s | $0,0000025 / GiB-s | $25,70 |
| CPU | 0,5 vCPU × 2.592.000 s = 1.296.000 vCPU-s | 375 vCPU-min = 22.500 vCPU-s | 1.273.500 vCPU-s | $0,000020 / vCPU-s | $25,47 |
| Festplatte (flüchtig) | 4 GB × 2.592.000 s = 10.368.000 GB-s | 200 GB-h = 720.000 GB-s | 9.648.000 GB-s | $0,00000007 / GB-s | $0,68 |
| Ausgehender Traffic (NA/EU) | 2 TB = 2048 GB | 1 TB | 1024 GB | $0,025 / GB | $25,60 |
Variable Gesamtsumme: etwa $77,44 pro Monat. Füge das $5 Workers Paid Abonnement hinzu, und die Gesamtsumme beträgt etwa $82,44 all-inclusive.
Eine vergleichbare Always-on PaaS-Instanz (wie sliplane oder ein kleiner VPS) könnte $7 bis $15 pro Monat pauschal kosten, sodass für Dienste mit hoher Auslastung und viel Bandbreite Cloudflare Containers fünf- bis zehnmal teurer sein können.
Faustregel: Workloads, die den größten Teil des Tages im Leerlauf sind, kosten in der Regel weniger auf Containers. Dienste mit konstanter, hoher Auslastung können auf einem Always-on-Host wie sliplane immer noch günstiger sein.
Aktuelle Beta-Einschränkungen
- Manuelle Skalierung, du rufst
get(id)auf. Autoscale und Latenz-Routing sind geplant. - Flüchtiger Speicher, sodass du nach jedem Schlafzustand ein frisches Dateisystem erhältst.
- 40 GiB RAM und 20 vCPU Kontolimit (vorübergehend).
- Nur Linux/amd64, noch keine ARM-Unterstützung.
- Kein eingehender TCP- oder UDP-Verkehr, da alles über einen Worker HTTP-Call geleitet wird.
Wann solltest du Containers vs. ein Always-on PaaS wählen
| Szenario | Containers | sliplane / always-on |
|---|---|---|
| Edge-nahe KI-Bildgenerierung, meist im Leerlauf | ✅ | |
| 24/7 REST-API mit über 70% Auslastung | ✅ einfacher, niedrigere konstante Kosten | |
| Sandbox pro Tenant (ein Container pro Benutzer) | ✅ | |
| Datenbank mit persistenten Volumes | ✅ |
Ein gemischtes Modell gewinnt oft. Du kannst deine persistente Datenbank auf sliplane (oder ähnlichem) laufen lassen, rechenintensive Burst-Workloads auf Cloudflare Containers und sie mit einem Worker verbinden.
Fazit
Cloudflare hat gerade im Wesentlichen serverless Fargate am Edge eingeführt: Docker Images, Abrechnung im Millisekundenbereich, globale Präsenzpunkte und kein Cluster-Overhead. Wenn die V8-Box der Workers sich jemals zu eng anfühlte oder dein Always-on Container die meiste Zeit im Leerlauf verbringt, probiere einen Beta-Container aus und sieh, was der Edge leisten kann.
Happy Hacking!
Viele Grüße,
Jonas, Mitgründer von sliplane
