Was ist PaaS? Platform as a Service erklärt

Ein Platform as a Service (PaaS) ist ein Betriebsmodell, bei dem Sie Ihren Anwendungscode oder ein fertiges Container-Image übergeben und der Anbieter die Anwendung für Sie betreibt. Sie installieren kein Betriebssystem, richten keinen Webserver ein, erneuern keine Zertifikate und starten keine abgestürzten Prozesse neu. Die Plattform baut, verteilt, routet und überwacht. Sie bestimmen, was die App tut und wie viel Leistung sie bekommt; wie diese Leistung bereitgestellt wird, ist Sache der Plattform.

Der Begriff stammt aus den drei klassischen Cloud-Servicemodellen, wie sie das US-Standardisierungsinstitut NIST definiert hat. Infrastructure as a Service (IaaS) liefert virtuelle Maschinen und Netze, Software as a Service (SaaS) eine fertige Anwendung. PaaS liegt dazwischen und richtet sich an Teams, die lieber Funktionen ausliefern als Server pflegen. Die drei Modelle im direkten Vergleich finden Sie unter PaaS, IaaS oder Serverless?.

Was eine App-Plattform übernimmt

Unabhängig vom Anbieter deckt ein PaaS fast immer dieselbe Kette ab:

• Build: erkennt die Programmiersprache im Repository (oft per Buildpack) oder nutzt Ihr Dockerfile und erzeugt daraus ein lauffähiges Image.
• Deployment: startet die neue Version, prüft, ob sie antwortet, und schaltet den Traffic um. Ein Rollback ist meist ein Klick.
• Routing und TLS: öffentliche URL, eigene Domain, automatisch ausgestellte Zertifikate.
• Skalierung: mehr Instanzen oder größere Instanzen per Regler oder Konfigurationswert, bei manchen Anbietern automatisch.
• Betrieb: Neustart bei Absturz, Logs, einfache Metriken, Verwaltung von Umgebungsvariablen und Secrets.
• Zusatzdienste: verwaltete Datenbanken, Caches, Queues und Cronjobs, die per Verbindungs-String angebunden werden.

Was bei Ihnen bleibt

Eine Plattform macht eine Anwendung nicht automatisch betriebsbereit. In Ihrer Verantwortung bleiben:

• Code, Bibliotheken und deren Sicherheitsupdates,
• Datenbankschema, Backups, die sich tatsächlich wiederherstellen lassen, und Löschfristen,
• Zugriffsrechte, der Umgang mit Secrets und die Frage, wer im Team deployen darf,
• die Kosten, auch bei plötzlichen Lastspitzen,
• rechtliche Fragen: wo personenbezogene Daten verarbeitet werden und auf welcher vertraglichen Grundlage.

Gerade der letzte Punkt wiegt im DACH-Raum schwerer, als viele Herstellerblogs vermuten lassen. Eine Plattform kann in Frankfurt laufen und trotzdem von einem Unternehmen betrieben werden, das nicht-europäischem Recht unterliegt. Den Unterschied zwischen Datenstandort und rechtlicher Kontrolle erklären wir unter souveräne Cloud.

Wann PaaS passt und wann nicht

Ausgangslage	PaaS geeignet?	Begründung
Kleines Team, Web-App oder API, gängiger Stack	Ja	spart Zeit für Serverpflege und Deployment-Pipelines
Prototyp, MVP, Nebenprojekt	Ja	schneller Start; Grenzen der Gratis-Stufe und Schlafmodus beachten
Gleichmäßig hohe, planbare Last	Oft nicht	Instanz- oder Nutzungspreise übersteigen dann einen gut betriebenen Server
Spezielles Netzwerk, GPUs, eigene Kernel	Selten	Plattformen standardisieren, Sonderfälle fallen heraus
Strenge Vorgaben zu Datenstandort oder Vergabe	Kommt darauf an	Region, Firmensitz und Vertragsunterlagen entscheiden

Drei Varianten: gehostet, selbst betrieben, auf Kubernetes

Gehostete Plattformen wie Railway, Render, DigitalOcean App Platform oder die französischen Anbieter Clever Cloud und Scalingo laufen vollständig auf der Infrastruktur des Anbieters. Sie zahlen für Bequemlichkeit. Eine Übersicht mit Regionen und Firmensitzen steht im Vergleich der Heroku-Alternativen.

Selbst gehostete PaaS wie Coolify, Dokku oder CapRover bringen den Heroku-artigen Ablauf auf einen gemieteten Server, etwa bei einem deutschen Hoster. Der Komfort bleibt, aber Updates, Backups und Überwachung des Servers liegen bei Ihnen. Die Unterschiede beschreiben wir unter PaaS selbst hosten.

Plattformen auf Kubernetes legen eine entwicklerfreundliche Schicht über einen Cluster. Das lohnt sich für Teams, die Kubernetes ohnehin betreiben. Für alle anderen ist es eine zusätzliche Ebene. Hintergründe dazu unter Was bedeutet Cloud-native?.

So rechnen PaaS-Anbieter ab

Es gibt zwei Grundmodelle. Bei instanzbasierter Abrechnung zahlen Sie einen festen Monatsbetrag pro laufender Instanzgröße; die Rechnung ist gut planbar. Bei nutzungsbasierter Abrechnung zahlen Sie für tatsächlich verbrauchte CPU, Arbeitsspeicher und Netzwerk; ruhende Apps sind günstig, stark genutzte schwerer vorherzusagen. Hinzu kommen Datenbanken, Speicher, ausgehender Datenverkehr (Egress) und teils Gebühren pro Teammitglied. Viele US-Anbieter rechnen in US-Dollar ab, was für Budgets in Euro einen Wechselkursanteil bedeutet.

Weil sich die Posten je nach Anbieter unterschiedlich zusammensetzen, lohnt eine Schätzung vorab. Der PaaS-Kostenrechner führt durch die Faktoren, einschließlich der Admin-Zeit, die Sie sparen oder zusätzlich aufwenden.

Lock-in vermeiden: vier Prüffragen

1. Lässt sich aus einem Standard-Dockerfile deployen, sodass dasselbe Image auch anderswo läuft?
2. Können Sie jederzeit Datenbank-Dumps in einem Standardformat exportieren?
3. Ist die Konfiguration proprietär oder nah an verbreiteten Formaten?
4. Nutzen Zusatzdienste offene Protokolle (PostgreSQL, Redis-kompatibel, S3-kompatibler Speicher)?

Wer die meisten Fragen mit Ja beantworten kann, wechselt später in Tagen statt Monaten.

Fazit

Ein PaaS ist der kürzeste Weg vom Code zur laufenden Anwendung mit HTTPS, Logs und Rollbacks. Für kleine Teams und neue Produkte ist es ein sinnvoller Standard, solange Sie drei Dinge im Blick behalten: wie der Preis mit dem Traffic wächst, wo die Plattform läuft und wer sie betreibt, und wie leicht Sie mit App und Daten wieder ausziehen können.