Vercel macht vieles leicht. Agents halt auch.
Ich habe meinen Stack von Vercel weggezogen. Nicht weil Vercel schlecht geworden wäre — Vercel ist weiter super. Sondern weil der Agent heute genau die CI-Schritte ausführt, die Vercel mir früher out-of-the-box abgenommen hat.
Ich musste nicht outsourcen. Ich wollte.
Vercel war lange die beste Antwort auf eine Frage, die ich gar nicht selbst beantworten wollte: wie bekomme ich eine reibungslose CI — für Tests und für Production gleichermaßen? Das ist keine Frage mit einer offensichtlichen Antwort. Vercel liefert out-of-the-box, was selbst schon schwer definierbar ist: Commit-Push → Tests → Preview-Deploy pro Branch → grüne Production-URL, ohne dass man sich den Flow erst ausdenken muss. Es war super. Es war einfach. Es war sogar lange gratis, und als ich irgendwann in den bezahlten Tarif gewechselt bin, habe ich das aus gutem Grund getan: ich habe bekommen, was ich bezahlt habe.
Was sich geändert hat, ist nicht Vercel. Was sich geändert hat, bin ich — oder genauer: das, was ich heute an meinem Arbeitsplatz einsetze.
Was Vercel für mich war
Vercel hat aus einem Haufen beweglicher Teile eine Pipeline gemacht, die man reibungslos bedienen kann. Commit-Push → Build → Deploy → CDN → URL, mit Preview-Deployments, automatischen Rollbacks, eingebauten Metrics. Kein nginx-Config selber schreiben, kein Zertifikat provisionieren, kein Deploy-Script bauen, kein Secret-Management koordinieren, kein Monitoring aufsetzen.
Ich hätte das alles selbst machen können. Ich habe es aber nicht gemacht, weil die Summe aus diesen Schritten als zu viel Aufmerksamkeit in Zeit verbucht wurde — und weil Vercel es wirklich gut macht. Wer weiß, was Vercel macht, weiß auch, wie mühsam es ist, so etwas selbst zu bauen — und dass diese Arbeit nie einmal erledigt ist. Sie kehrt zurück, im ungünstigen Moment, ohne Ankündigung.
Für diese Abnahme habe ich gerne bezahlt. Ich stehe auch heute dazu.
Was sich geändert hat
Zwischen damals und jetzt ist eine Sache schneller passiert, als die meisten Abonnement-Rechnungen mitgekommen sind: Agents sind gut geworden.
Nicht brauchbar. Nicht unterhaltsam. Gut. Gut in dem Sinne, dass die vielen Schritte, die Vercel mir abgenommen hat, heute mein Agent ausführt. Die Pipeline, die Vercel zuverlässig gebaut hat, lässt sich mit einem guten Agent-Setup auch selbst führen — in der gleichen Zeit, mit derselben Trefferquote, mit demselben es geht einfach. Vercel macht vieles leicht. Agents halt auch.
Ich habe nicht für Infrastruktur bezahlt. Ich habe für die Aufmerksamkeit bezahlt, die Infrastruktur braucht. Diese Aufmerksamkeit kann ich jetzt delegieren, ohne eine Rechnung dafür zu bezahlen.
Der Unterschied ist nicht ideologisch, er ist einfach praktisch: zwei Wege führen jetzt zum selben Ergebnis, und der eine gibt mir mehr Kontrolle.
Der Agent denkt mit
Ein weiterer Punkt wurde mir erst beim Arbeiten klar: der Agent baut die CI/CD-Kette nicht einmal und dann steht sie. Er baut sie on the way. Ich sage einmal "so will ich es deployen" — spontan, formlos, vielleicht unvollständig — und er setzt ein passgenaues Skript auf. Wenn sich später herausstellt, dass ich einen zusätzlichen Healthcheck brauche, einen anderen Rollback-Trigger, einen Branch-spezifischen Build-Step, dann passt er das Skript an. Er denkt nicht jedesmal alles neu; er ergänzt und modifiziert.
Embrace the change. Wenn sich die Anforderungen ändern, ändert sich die Kette. Kein jetzt steht die Pipeline, jetzt ist die Config eingefroren, jetzt bewegen wir uns in dem, was vor sechs Monaten sinnvoll war. Der Agent denkt mit, und er zwingt mich nicht in eine Kiste.
Was der Agent nicht kann
Eine Sache kann mir der Agent nicht abnehmen: ein globales CDN und echte Edge-Skalierung.
Das ist keine Convenience, das ist Engineering-Arbeit an einer Ebene, die man nicht an einem Nachmittag löst. Ein Netzwerk von Edge-Knoten, Cache-Invalidierung, DDoS-Mitigation, intelligentes Routing — das ist kein Deploy-Script-Problem. Das ist Infrastruktur-im-eigentlichen-Sinne, die man nicht mit lokalen Tools und einem Agent ersetzt.
Wenn ich an den Punkt komme, wo eines meiner Projekte echte Nutzerzahlen sieht und meine VM das nicht mehr mit einem Standardzustand bedient, dann würde ich jederzeit wieder bezahlen. Nicht zurück, weil der Wechsel ein Fehler war, sondern weiter — mit einem klaren Gefühl dafür, wofür genau ich Vercel dann bezahle. Nicht für die Convenience, sondern für die Skalierung.
Der zweite Trigger
Parallel stand sowieso die Domain-Migration an — die langfristige Antwort auf die Frage, warum eine deutsche Domain ein Projekt trägt, dessen Zielgruppe international ist. openape.at → openape.ai, mit GitHub-Org, IdP und allem, was dranhängt.
Wenn du eine Domain-Migration planst, fasst du sowieso DNS, SSL, nginx-Vhosts, Mail-Routing und Service-Discovery an. In dem Moment, in dem ich die .ai-Subdomains ohnehin anfasse, kostet es kaum Extra-Aufwand, das Ziel frei zu wählen. Die Migration war sowieso Operations. Die Wahl, wo die Services liegen, war dann frei — und ich habe mich für die eigene VM entschieden.
Was umgezogen ist
Eine VM, läuft bei mir. Das, was jetzt dort liegt:
id.openape.ai— der Identity Provider. Der, der JWTs signiert. Der mit allen sensiblen Secrets.docs.openape.ai— die Dokumentation.mail.openape.ai/proxy.openape.ai— Transport-Layer. Mail-Sender für IdP-Notifications, Proxy für Agent-Webhook-Flows.www.openape.ai— die Landing.delta-mind.at(dieses Blog) — auch mit umgezogen. rsync + nginx. Auto-Deploy per GitHub Action, die die Build-Artefakte über SSH auf die VM pusht.
Dazu kam ein dedizierter Service-User, systemd-Units pro Service, ein auto-deploy-Script für jeden Push, Logrotate- und Health-Check-Regeln. Alles Arbeit, die ich früher nicht gemacht hätte. Alles Arbeit, die der Agent neben mir zum größten Teil geschrieben hat.
Was ich beim Umzug gelernt habe
Self-Hosting ist nicht frei von Kosten — nur von anderen Kosten. Drei Dinge, die mir aufgefallen sind:
Silent Failures werden sichtbar. Vercel hat mir nie gesagt, wenn eine Mail nicht zugestellt wurde — der Resend-Call lief durch, der Response war 2xx, die Mail kam nicht an. Auf der eigenen VM habe ich das Delivery-Failure-Surfacing explizit rein gebaut: wenn Resend eine Zustellung ablehnt, wird der IdP-Request mit einem sichtbaren Fehler zurückgegeben, nicht stillschweigend geschluckt. Das hätte ich auf Vercel genauso machen müssen. Habe ich aber nicht, weil das ganze System sich unsichtbar angefühlt hat — und unsichtbare Systeme werden selten gehärtet.
Ops-Hygiene wird zur Verantwortung. Auf Vercel hatte ich keinen Grund, mich zu fragen, ob meine users- und shapes-Tabellen beim ersten Start des Services existieren. Auf der eigenen VM ist genau das einer der ersten Bugs, auf die ich gestoßen bin: der IdP startet auf einem frischen Setup nicht, weil die Tabelle nicht da ist. Fix: Auto-Erstellung auf Startup. Keine Magie. Aber jetzt mein Job, nicht jemandes anders.
Pre-Checks sauber stapeln. OAuth-Codes, Refresh-Tokens, JTIs, Signing Keys — alles Sachen, die auf Vercel als Environment-Variable oder im KV-Store lagen, funktionierten, und nie hinterfragt wurden. Beim Umzug habe ich alle in dieselbe Sequenz gepackt: Service-Start → Tabellen prüfen → Keys prüfen → JTIs prüfen → fertig starten. Einen einzelnen Ort dafür gab es vorher nicht. Jetzt gibt es einen.
Das sind keine neuen Lessons. Sie waren nur unsichtbar, weil die Plattform sie unsichtbar gemacht hat — was kein Vorwurf ist, sondern exakt die Haltung, für die man eine Plattform nutzt.
Die finanzielle Nebenwirkung
Ich habe das bewusst in die Mitte gestellt und nicht an den Anfang, weil es nicht der Haupttreiber war: mit steigender Nutzung — viele Test-Projekte, höhere Iterationen, mehr Builds — wird eine Plattform-Rechnung naturgemäß weniger berechenbar. Eine feste VM hat einen festen Preis. Das macht in einer Phase, in der ich aktiv neue Sachen ausprobiere, fix pro Monat sicherer planbar als je mehr ich iteriere, desto mehr Builds, desto teurer wird der Versuch.
Das ist ein schöner Seiteneffekt der Entscheidung. Es ist nicht der Grund.
Die größere Sache
Ich habe ein Projekt gebaut, das sich damit beschäftigt, wie Kontrolle über Entscheidungen an der richtigen Stelle liegt. OpenApe zieht die Policy-Entscheidung vom Agent zum User, weil der Agent den Workflow-Kontext nicht hat. Dasselbe Prinzip gilt, nur auf einer anderen Ebene, für die eigene Infrastruktur: wer die Plattform kontrolliert, kontrolliert die Entscheidungen, die auf ihr getroffen werden.
Solange eine Plattform dir passt, ist das ein guter Deal. Vercel hat mir lange gepasst und passt vielen Projekten weiter. Aber bei einem Projekt, das seinerseits Identity und Grants baut, um solche Strukturen transparent und revokeable zu machen, wird es irgendwann inkonsistent, die Struktur darüber nicht in die eigene Hand zu nehmen. Das ist keine Abkehr von Managed-Platforms. Das ist eine Konsequenz aus dem, was ich gerade baue.
Was das nicht ist
Es ist keine Empfehlung für Self-Hosting als Default.
Für ein neues Projekt, das in den nächsten drei Monaten einen schnellen Launch braucht, ist Vercel weiter der richtige Weg. Die ersten hundert Nutzer sind wichtiger als ein eigener nginx-Stack. Das ist nicht geändert.
Was sich geändert hat, ist die Grenze, an der Self-Hosting wieder eine realistische Option wird. Früher lag sie bei großer Scale + dediziertem Ops-Team. Jetzt liegt sie bei ein Entwickler mit einem guten Agent-Setup und einem Nachmittag pro Service.
Ich baue meine Services inzwischen sowieso edge-kompatibel für die eigene Instanz. Wenn der Punkt kommt, an dem ich CDN und Edge-Skalierung ernsthaft brauche, bin ich in einer Domain-TTL zurück auf Vercel — dann genau für das, wofür Vercel wirklich gebaut ist.
Ich habe nicht gewechselt, weil Vercel schlecht geworden wäre. Ich habe gewechselt, weil der Agent heute das macht, was ich früher an Vercel outsourced habe. Vercel macht vieles leicht. Agents halt auch. Und für das, was Vercel leichter macht als jeder Agent — CDN, Edge, Skalierung auf einem Niveau, das kein Wochenend-Setup je erreichen wird — würde ich jederzeit wieder bezahlen.
Setup: eine einzelne VM, Debian, nginx, systemd, rsync-basiertes Deploy pro Service. Die Services sind die, die ich oben aufgeführt habe. Code für den IdP: github.com/openape-ai/openape, MIT-lizenziert. Die eigentliche Server-Config liegt im privaten Ops-Repo — nicht weil sie geheim ist, sondern weil sie meine ist.