Ein Kunde rief mich Anfang Januar an, absolut begeistert. „Gautam, ich habe gerade gelesen, dass Vercel jetzt Docker unterstützt. Wir können unsere DigitalOcean-Droplets abschalten, ja?" Er betrieb drei Droplets, zwei davon à 24 Dollar pro Monat, einen à 48 Dollar. Er hatte eine Tabellenkalkulation bereit. Er wollte Geld sparen und er wollte es sofort sparen.
Ich sagte ihm, er solle zwei Wochen warten, während ich es tatsächlich teste. Gut, dass er zugehört hat.
Hier ist das Ding: Vercel's Container-Unterstützung ist wirklich beeindruckend. Und ein VPS ist immer noch nicht tot. Beide Aussagen sind gleichzeitig wahr, und die Nuance zwischen ihnen ist es wert, verstanden zu werden, bevor du anfängst, alles zu Vercel's Infrastruktur zu docker push-en und dich fragst, warum deine WebSocket-Verbindungen immer wieder abbricht.
Was Vercel Tatsächlich Angekündigt Hat
Vercel's Docker-Unterstützung, ausgerollt durch ihre Build Output API und später für die allgemeine Nutzung formalisiert, ermöglicht es dir, eine Dockerfile zu versenden und Vercel die Container-Runtime zu überlassen. Keine Begrenzung auf Next.js-Konventionen oder Serverless-Funktionsdateistrukturen mehr. Du schreibst deine Dockerfile, Vercel baut sie, führt sie aus.
Das ist eine echte Verschiebung. Vorher, wenn du ein FastAPI-Backend oder einen Custom Node-Server mit etwas Exotischem hattest, musstest du es entweder in die Form einer Serverless Function pressen oder einen VPS neben deinem Vercel-Frontend am Laufen halten. Letzteres ist das, was die meisten von uns gemacht haben. Es war nervig, aber es funktionierte.
Wie die Runtime Tatsächlich Aussieht
Vercels Container-Runtime ist kein reines Docker auf Bare Metal. Es ist näher daran, was du auf einem verwalteten Container-Service bekommen würdest. Dein Container erhält eine Anfrage, Vercel leitet sie weiter, der Container verarbeitet sie. Persistente Prozesse funktionieren. Du kannst etwas wie einen Python WSGI Server oder eine Go HTTP Binary laufen lassen. Long-Running Tasks innerhalb eines einzelnen Request-Lebenszyklus sind in Ordnung.
Aber die Constraints spielen eine Rolle. Container können auf null skalieren. Cold Starts existieren. Und entscheidend: Du bekommst keinen persistenten Disk-Speicher. Wenn deine App in das lokale Dateisystem schreibt und erwartet, dass diese Dateien beim nächsten Request da sind, wirst du eine schlechte Zeit haben.
Wo Vercel Containers Wirklich Brillieren
Ich betreibe eine Django REST API auf Vercel Containers seit März. Es ist ein relativ einfacher, Read-Heavy Service für einen Media-Kunden, hauptsächlich GET-Requests, die auf eine Neon Postgres Datenbank zugreifen. Keine Dateischreibvorgänge. Keine Background Jobs. Keine WebSockets.
Es war ausgezeichnet. Deploy Previews funktionieren. Die GitHub Integration bedeutet, dass jeder PR seine eigene Umgebung bekommt. Die Cold-Start-Latenz auf diesem speziellen Container liegt bei etwa 800ms bis 1,2 Sekunden beim ersten Hit nach Idle, was schlecht klingt, aber akzeptabel ist, wenn der Traffic des Kunden bursty und vorhersehbar ist.
Die Kosten für diesen Service? Etwa $20/Monat mit Vercels Pro Plan eingerechnet. Das Äquivalent auf DigitalOcean App Platform wäre ähnlich. Ein Raw Droplet wäre billiger, aber wir würden ihn selbst verwalten.
Das Szenario, in dem das ein klarer Sieg Ist
Denk an das typische Agency-Projekt. Eine Marketing-Website mit einem Headless CMS, eine leichte API für ein Kontaktformular oder eine Custom Logic, und die Notwendigkeit für schnelle Deploys. Vorher hättest du Vercel für das Frontend und einen $6 Droplet für die kleine API. Jetzt kannst du alles auf Vercel packen, ein Dashboard nutzen, Deploy Previews auch für die API haben. Weniger Dinge zu verwalten. Weniger Dinge, die du vergessen kannst zu aktualisieren.
Für Freelancer, die fünf bis fünfzehn Client-Websites betreuen, rechtfertigt diese operative Einfachheit echtes Geld, selbst wenn die Rechenkosten leicht höher sind.
Wo ein VPS immer noch gewinnt. Eindeutig.
Richtig. Hier muss ich direkt sein, denn die Begeisterung um Vercel Container hat einige Entwickler zu teuren Fehlern verleitet.
Persistente Dateisystemoperationen. Wenn deine App PDFs generiert und diese lokal speichert, bevor sie zu S3 verschoben werden, in Ordnung, diese spezifische Operation funktioniert. Aber wenn du etwas wie eine selbstgehostete Meilisearch-Instanz betreibst, die ihren Index auf die Festplatte schreibt, brauchst du persistenten Speicher. Vercel bietet dir kein angehängtes Volume. Du müsstest etwas wie einen verwalteten Meilisearch-Service hinzufügen oder es auf einem VPS betreiben. Punkt.
WebSockets und langlebige Verbindungen. Vercel's serverlose und Container-Umgebungen haben Request-Timeouts. Ich bin darauf bei einem Seahawk-Projekt Ende 2024 gestoßen, noch bevor die Docker-Unterstützung überhaupt verfügbar war. Wir haben ein Echtzeit-Zusammenarbeitswerkzeug für einen kleinen SaaS-Kunden gebaut. Wir haben alles versucht, um es auf Serverless-Infrastruktur zum Laufen zu bringen. Schließlich haben wir den WebSocket-Server auf einen 12 Euro/Monat Hetzner VPS verlagert. Problem gelöst. Der VPS läuft seither unterbrechungsfrei.
Background Worker und Cron in großem Maßstab. Ja, Vercel hat Cron Jobs. Die sind für einfache geplante Aufgaben in Ordnung. Aber wenn du etwas wie Celery Worker betreibst, die kontinuierlich eine Warteschlange von Jobs verarbeiten, willst du einen Prozess, der einfach... läuft. Ein VPS macht das mühelos. Bei Vercel Containern arbeitest du gegen den Strich.
Kosten bei großem Volumen. Das ist das, was die Leute überrascht. Bei niedrigem bis mittlerem Traffic sind Vercel Container konkurrenzfähig. Aber bei genuinely hohem Request-Volumen fangen sich die Pro-Request-Kosten an zu summieren. Ein 48 Euro/Monat Hetzner Dedicated Server verarbeitet den Traffic, der auf Vercel im Peak mehrere hundert Euro kosten würde. Mein Client, der seine Droplets stilllegen wollte? Einer davon lief ein hochfrequentes internes Dashboard. Ich habe die Zahlen durchgerechnet. Den Droplet zu behalten war 18 Pfund/Monat günstiger, selbst wenn man gelegentliche Wartungszeit einrechnet.
Die spezifischen Workloads, die ich niemals zu Vercel migrieren würde
Lass mich konkret sein. Das sind die Dinge, die ich aktiv zu einem VPS leite, egal was Vercel noch veröffentlicht:
- Selbstgehostete Datenbanken. Sogar ein kleines Postgres-Replikat für Read-Performance. Vercel ist kein Datenbankhost. Nutze es mit Neon, Supabase oder PlanetScale, aber versuche nicht, Postgres selbst dort zu betreiben.
- Mediaverarbeitung. FFmpeg-Jobs, Warteschlangen zur Bildgrößenänderung, alles CPU-intensive mit unvorhersehbaren Laufzeiten. Ein $20 Hetzner VPS mit 2 vCPUs erledigt das besser und günstiger.
- Interne Tools, die rund um die Uhr laufen. Monitoring-Agenten, Log-Aggregatoren, benutzerdefinierte Proxy-Server. Diese sollten einfach laufen. Immer. Skalierung auf Null ist hier der Feind.
- Alles, das eine GPU berührt. Selbstverständlich, aber es lohnt sich, es zu sagen.
Und umgekehrt: Das würde ich heute mit Vertrauen auf Vercel Container legen:
- Leichte REST-APIs (FastAPI, Express, Gin) ohne persistenten Zustand
- Containerisierte Next.js- oder Remix-Apps mit benutzerdefinierter Serverkonfiguration
- Interne APIs, auf die nur während der Geschäftszeiten zugegriffen wird (Skalierung auf Null ist hier wirklich großartig)
- Jeder Service, bei dem du wirklich pro PR Deploy-Vorschauen möchtest
Die versteckte Kostenfalle, über die keiner spricht: Betriebskomplexität
Ich habe über die Jahre hinweg über 12.000 Websites bei Seahawk gebaut. Das Nummer-eins-Problem, das Agenturen und Freelancer beißt, sind nicht die Compute-Kosten. Es ist der Betriebsaufwand.
Ein VPS klingt mit $6/Monat billig. Und er ist billig. Aber dann patchst du ihn, überwachst ihn, konfigurierst Nginx, richtest fail2ban ein, loggst dich gelegentlich um 23 Uhr per SSH ein, weil etwas seltsam läuft. Das ist nicht kostenlos. Das ist Zeit, und Zeit ist teuer.
Vercel nimmt dir das alles ab. Genauso wie Railway, Render und Fly.io. Der echte Wettbewerb hier ist nicht „Vercel gegen einen VPS im luftleeren Raum". Es ist „Managed-Platform-Gebühr gegen Ops-Zeit-Gebühr". Für Solo-Operatoren und kleine Agenturen ist die Managed-Platform-Gebühr meist das bessere Geschäft.
2019 gab mir ein Kunde ein Briefing, das die Verwaltung ihres Ubuntu-Servers umfasste. Ich habe entsprechend kalkuliert. Sechs Monate später wurde ich immer noch wegen Festplattenspeicher-Warnungen eines Servers kontaktiert, den ich technisch „verwaltete", aber komplett vernachlässigt hatte. Seitdem bin ich viel bewusster darin, welche Infrastruktur ich in Besitz nehme und wofür ich eine Plattform bezahle.
Das Framework, das ich wirklich nutze, um zu entscheiden
Kein magisches Flussdiagramm. Nur eine Reihe von Fragen, die ich bei jedem neuen Projekt stelle:
- Schreibt dieser Service auf die Festplatte und erwartet, dass diese Schreibvorgänge bestehen bleiben? Falls ja, brauchst du einen VPS oder verwalteten Speicher.
- Hält dieser Service Langzeit-Verbindungen (WebSockets, SSE, gRPC-Streams)? Falls ja, VPS oder eine Plattform, die dies explizit unterstützt, wie Fly.io.
- Ist dieser Service für längere Zeit CPU-gebunden? Vercel-Container haben eine CPU-Obergrenze. VPS gewinnt.
- Braucht das Team Deploy-Previews und GitOps ohne Nachdenken? Vercel gewinnt.
- Wird der Traffic konstant und in hohem Volumen sein? Rechne die Zahlen durch. Ein VPS ist meist ab einem bestimmten Schwellwert billiger.
- Ist das ein One-Man-Show oder eine kleine Agentur, die sich nicht mit Servern auseinandersetzen möchte? Vercel ist die Premium-Investition wert.
Falls die Fragen 1, 2 oder 3 mit ja beantwortet werden, greife ich zu Hetzner oder DigitalOcean. Alles andere ist eine Diskussion wert.
Was 2026 wirklich für die Infrastruktur bedeutet
Plattformen werden besser beim persistenten Speicher. Fly.io hat Fly Volumes. Render hat persistente Disks. Vercel wird wahrscheinlich irgendwann etwas Ähnliches hinzufügen, angesichts wie oft es angefordert wird. Die Lücke zwischen „verwalteter Plattform" und „VPS mit vollständiger Kontrolle" wird kleiner.
Aber kleiner werden ist nicht dasselbe wie schließen. Und die Wirtschaftlichkeit der reinen Rechenleistung hat sich grundlegend nicht verändert. Eine Hetzner CAX11 ARM-Instanz für 3,79 €/Monat bietet immer noch unglaublich gutes Preis-Leistungs-Verhältnis für die richtige Workload. Niemand schlägt das auf einer verwalteten Plattform bei gleichwertiger Rechenleistung.
Der ehrliche Zustand der Welt 2026 ist dieser: Der VPS ist nicht tot. Der VPS ist zunehmend optional. Das sind unterschiedliche Dinge.
Die meisten neuen Projekte, die ich bei Seahawk starte, laufen standardmäßig auf Vercel oder Railway, es sei denn, etwas aus der Frageliste oben führt zu einer anderen Antwort. Wir haben die Anzahl der aktiven VPS-Instanzen, die wir verwalten, in den letzten achtzehn Monaten wahrscheinlich um etwa 40 % reduziert. Aber die verbleibenden sind aus guten Gründen da und werden nicht verschwinden.
FAQ
Können Vercel-Container Docker Compose für lokale und produktive Parity ersetzen?
Irgendwie, aber nicht wirklich. Docker Compose geht es um die Orchestrierung mehrerer Services zusammen lokal. Vercel läuft mit einem einzelnen Container pro Deployment. Falls dein Stack einen Web-Server, einen Worker und Redis alle in einer Compose-Datei hat, kann Vercel den Web-Server-Teil handhaben. Du würdest immer noch auf verwaltete Redis zeigen müssen (Upstash ist die häufige Wahl) und den Worker separat handhaben. Lokale Parity ist besser als früher, aber Compose-zu-Vercel ist keine direkte Übersetzung.
Was passiert mit Vercel-Containern, wenn sie auf null skaliert werden?
Der Container-Prozess stoppt. Wenn eine neue Anfrage einkommt, startet Vercel ihn neu. Diese Boot-Zeit ist deine Cold-Start-Latenz. Bei kompilierten Binärdateien (Go, Rust) liegt das oft unter 500ms. Bei größeren Runtimes wie JVM-basierten Apps kann es 2 bis 4 Sekunden dauern. Es lohnt sich, das vor dem Commit im Staging zu testen, denn manche Kunden werden einen 3-Sekunden-First-Load definitiv bemerken.
Ist Vercels Container-Support im kostenlosen Hobby-Plan verfügbar?
Stand Anfang 2026: Nein. Container-Deployments erfordern mindestens den Pro-Plan. Der Hobby-Tier unterstützt weiterhin serverlose Funktionen und statische Seiten. Es lohnt sich, Vercels Pricing-Seite direkt zu überprüfen, da sich das schon geändert hat und sich wahrscheinlich wieder ändern wird.
Wann sollte ich Fly.io statt Vercel oder einem rohen VPS verwenden?
Fly ist meine erste Wahl, wenn ich persistente Prozesse, globale Verteilung nah bei den Nutzern brauche und keine Server-Konfiguration verwalten möchte. Es sitzt in einem interessanten Mittelfeld. Du deployest Container, bekommst aber mehr Kontrolle über Regionen, Machine-Größen und persistente Volumes als Vercel bietet. Ich nutze es für lange laufende APIs und alles mit WebSocket-Anforderungen, das in mehreren Regionen sein muss. Der Tradeoff ist, dass die DX etwas aufwendiger ist als Vercels GitHub-Integration.
---
Der VPS ist nichts, das du aus Gewohnheit standardmäßig nutzen solltest. Aber es ist auch nichts, das du aus Begeisterung aufgeben solltest. Kenne deine Workload. Rechne die Zahlen durch. Und warte vielleicht zwei Wochen, bevor du irgendetwas abschaltest.
Weiterführende Lektüre: AI-Suchschlüsselwortforschung 2026: Was es ist, warum traditionell, technisches SEO und AI-Suche.