GhostlyInc Hosting-Review-Lab
DigitalOcean App Platform Test 2026: PaaS-Preise, Skalierung, Limits und sinnvolle Einsatzfälle
Die DigitalOcean App Platform ist ein starker Managed-PaaS, wenn du Web-Apps, APIs, statische Seiten, Worker und geplante Jobs veröffentlichen willst, ohne eigene Server zu betreiben. Weniger sinnvoll ist sie, wenn du Root-Zugriff, persistenten lokalen Speicher, tiefe Netzwerkkontrolle oder die niedrigstmögliche VPS-Rechnung brauchst.
Kurzes Fazit
App Platform ist am stärksten, wenn Deployment-Geschwindigkeit wichtiger ist als Serverkontrolle
Wähle App Platform, wenn dein Team Git-Deployments, Managed Builds, HTTPS, Routing, Logs, Skalierung und DigitalOcean-Datenbankanbindungen an einem Ort haben möchte. Nimm lieber ein Droplet, Kubernetes oder eine andere Cloud, wenn du SSH, eigenes Networking, stateful Disks, nicht unterstützte Systempakete oder sehr gezieltes Runtime-Tuning brauchst.
Käuferprofil
DigitalOcean App Platform: Vorteile, Grenzen und für wen sie infrage kommt
Die entscheidende Frage ist nicht, ob App Platform eine App deployen kann. Das kann sie. Wichtiger ist, ob dir eine Managed Platform so viel Arbeit abnimmt, dass du ihre Grenzen bei Speicher, Shell-Zugriff, Networking und Runtime-Kontrolle akzeptierst.
Wo App Platform besonders stark ist
- Schneller Weg von Git oder Container-Image zu einer öffentlichen Produktions-URL
- Unterstützt statische Seiten, Webservices, Worker, geplante Jobs und Apps mit mehreren Komponenten
- Automatisches HTTPS, eigene Domains, Rollbacks, Logs, Metriken, Alerts und Health Checks reduzieren Routineaufwand im Betrieb
- Buildpacks decken gängige Stacks wie Node.js, Python, Go, PHP, Ruby, Rust und .NET ab; Dockerfiles lösen viele Spezialfälle
- Request-basiertes Autoscaling macht traffic-getriebene Services leichter steuerbar, als ältere App-Platform-Reviews vermuten lassen
- Gute Ökosystem-Passung, wenn du bereits DigitalOcean Managed Databases, Spaces, Container Registry, OpenSearch, Kafka oder VPC-Networking nutzt
Wo ein anderer Anbieter besser passen kann
- Kein SSH- oder SFTP-Zugriff auf Container, daher ist tiefes Debugging im Vergleich zu einem VPS eingeschränkt
- Keine persistenten Volumes; lokale Dateien solltest du als temporär behandeln
- Die günstigsten Shared-CPU-Größen sind nicht die ganze Produktionsrechnung, sobald Worker, Jobs, Datenbanken, Traffic und IPs dazukommen
- Einige Limits übersieht man leicht, etwa Build-Timeouts, Linux-AMD64-Image-Anforderungen, SMTP-Einschränkungen und fehlende direkte IPv6-Service-Verbindungen
- CPU-basiertes Autoscaling braucht weiterhin Dedicated-CPU-Pläne, was die Kostenrechnung für CPU-lastige Apps verändert
- Weniger flexibel als Droplets oder Kubernetes bei ungewöhnlichen Runtimes, nativen Abhängigkeiten, eigenen Daemons und Low-Level-Networking
Inhaltsverzeichnis
Aktueller Produktstand
Was die DigitalOcean App Platform heute wirklich bietet
App Platform ist die Managed-Anwendungsschicht von DigitalOcean. Sie kann aus Git-Repositories bauen, Container-Images deployen, statische Seiten, Webservices, Worker und Jobs ausführen und Apps mit DigitalOcean-Diensten wie Managed Databases, Spaces, OpenSearch, Kafka und VPC-Networking verbinden.
Services und APIs
Nutze App Platform für Node.js, Python, Go, PHP, Ruby, Docker und andere HTTP-Services, die aus Git oder einer Container Registry deployed werden sollen.
Statische Seiten und SPAs
Statische Komponenten sind sinnvoll für Marketing-Seiten, Dokus, Dashboards und Frontend-Apps, die sich zu Dateien bauen lassen und über den CDN-Pfad von DigitalOcean ausgeliefert werden.
Worker und Jobs
Worker übernehmen Queue-Consumer und Hintergrundprozesse. Jobs erledigen Deploy-Aufgaben und geplante Cron-ähnliche Arbeiten, ohne eine HTTP-Route bereitzustellen.
Managed-Integrationen
Der Nutzen wächst, wenn du Managed Databases, Object Storage, private Netzwerke, Log Forwarding, Alerts und Container-Registry-Workflows einbindest.
Passende Einsatzfälle
Wann App Platform die richtige Hosting-Wahl ist
Ein Managed-PaaS kann günstiger sein als ein VPS, sobald du Server-Setup, Patches, Deploy-Skripte, SSL, Rollbacks, Logs und Scaling-Aufwand mitrechnest. Er kann aber auch teuer oder zu eng werden, wenn deine App Low-Level-Kontrolle braucht. Diese Tabelle hilft vor der Migration.
| Workload | Eignung | Grund |
|---|---|---|
| Kleine SaaS-App, API oder internes Dashboard | Sehr passend | Du bekommst Deployments, HTTPS, Logs, Rollbacks und Skalierung, ohne Linux, Nginx, Prozessmanager oder SSL-Erneuerung selbst zu pflegen. |
| Statische Seite mit kleiner API | Gut geeignet | Halte das Frontend als statische Komponente schlank und betreibe die API als Service. Prüfe aber Traffic- und Servicepreise, bevor du von kostenlos ausgehst. |
| Queue-Worker plus Web-App | Gut geeignet | Worker sind eigene App-Komponenten, dadurch können Web- und Hintergrund-Workloads dieselbe App-Spezifikation und dasselbe Environment-Modell nutzen. |
| Datenbank-App bereits auf DigitalOcean | Sehr passend | Managed PostgreSQL, MySQL, MongoDB, Valkey, OpenSearch, Kafka und VPC-Funktionen können viel Integrationsarbeit sparen. |
| App mit persistenten lokalen Uploads | Ungeeignet | Nutze Spaces, eine Managed Database oder eine andere Plattform. Das lokale Dateisystem der App Platform ist temporär und kein Volume-System. |
| Eigener Server-Stack mit Root-Debugging | Droplets oder Kubernetes nutzen | Wenn dein normaler Workflow SSH, SFTP, Paketinstallationen, eigene Daemons oder Systemlogs braucht, wird sich App Platform eng anfühlen. |
Kosten realistisch betrachtet
Die App-Platform-Preise sind klar, aber die Gesamtrechnung hängt von den Komponenten ab
Das aktuelle Preismodell berechnet App-Services und Jobs nach gewählter Container-Größe und laufenden Containern, mit sekundengenauer Abrechnung und Mindestbeträgen. Reine Static-Site-Apps können bei kleinem Umfang günstig oder kostenlos sein, Produktions-Apps bestehen aber oft aus Webservice, Worker, Datenbank, Traffic, Observability und manchmal dedizierten Egress-IPs.
Shared CPU startet günstig
Die aktuellen Docs nennen kleine Shared-CPU-App-Services ab 5 US-Dollar pro Monat. Das ist ein sinnvoller Einstieg für einfache Apps, aber Skalierung, RAM, Traffic und zusätzliche Komponenten bestimmen die echte Rechnung.
Kostenlos ist eng begrenzt
DigitalOcean erlaubt aktuell bis zu drei reine Static-Site-Apps mit kleinem ausgehendem Datenvolumen. Verstehe das eher als Landingpage-Tier, nicht als kostenlose Produktionsplattform für Traffic.
Dedicated CPU verändert die Rechnung
CPU-basiertes Autoscaling erfordert Dedicated-CPU-Pläne, während request-basiertes Autoscaling geeignete Services auf Shared- oder Dedicated-CPU-Plänen unterstützt. Teste Kosten und Reaktionsverhalten.
Traffic, Datenbanken und IPs zählen
Ausgehender Traffic über Freimengen hinaus, Development Databases, Managed Databases und dedizierte Egress-IPs sind eigene Kostenpunkte. Vergleiche die komplette App-Architektur, nicht nur den Compute-Headline-Preis.
Deployment-Workflow
Ein sauberes App-Platform-Setup beginnt vor dem ersten Deployment
Mit einem Demo-Repository wirkt App Platform fast zu einfach. Echte Apps brauchen mehr Disziplin: sauber getrennte Umgebungsvariablen, Build-Kommandos, Health Checks, Migration-Jobs, Log-Zugriff, Rollback-Verhalten und einen klaren Weg von Staging nach Produktion.
Git oder Container-Image bewusst wählen
GitHub, GitLab, Bitbucket, öffentliches Git, DOCR, Docker Hub und GitHub Container Registry sind sinnvolle Optionen. Wähle die Variante, die dein Release-Prozess sicher wiederholen kann.
Runtime-Versionen festpinnen
Verlass dich nicht blind auf die Runtime, die die Plattform erkennt. Pinne Node, Python, Go, PHP, Ruby, .NET oder Docker-Basisversionen, wo dein Stack es zulässt.
Build- und Runtime-Variablen trennen
Nutze geheime Umgebungsvariablen bewusst und entscheide, ob ein Wert beim Build, zur Laufzeit oder in beiden Phasen gebraucht wird. Vermeide, dass Production-Secrets in Preview-Kontexte geraten.
Migrationen explizit machen
Nutze bei Bedarf Deploy-Time-Jobs für Migrationen und Post-Deploy-Aufgaben. Ein Webservice, der bei jedem Start still Migrationen ausführt, ist schwerer kontrollierbar.
Echten Health Check hinzufügen
Ein Health Check sollte zeigen, dass die App Traffic bedienen und wichtige Abhängigkeiten erreichen kann, nicht nur ein statisches OK aus einem halb gestarteten Prozess zurückgeben.
Rollback vorher durchspielen
App Platform kann auf kürzlich erfolgreiche Deployments zurückrollen, aber Datenbankmigrationen, Queues und externe Integrationen brauchen trotzdem eine eigene Rollback-Strategie.
Skalierung
Skalierung ist nützlich, muss aber zu deiner App passen
App Platform unterstützt vertikale Skalierung über größere Container und horizontale Skalierung über mehr Container. CPU-basiertes Autoscaling ist an Dedicated-CPU-Pläne gebunden, während request-basiertes Autoscaling für geeignete Service-Komponenten auf Shared- und Dedicated-CPU-Plänen funktioniert. Damit ist die aktuelle Skalierung flexibler, als ältere Reviews oft vermuten lassen.
| Scaling-Frage | Was du testen solltest | Warum es wichtig ist |
|---|---|---|
| Vertikale Skalierung | Container-Größen unter produktionsnaher Last wechseln | Ein größerer Container kann günstiger und stabiler sein als viele kleine Replikas, wenn deine App speicherlastig ist oder langsam startet. |
| Horizontale Skalierung | Minimale und maximale Containerzahl erhöhen | Zwei oder mehr Container sind auch für Hochverfügbarkeit wichtig. Ein Container kann günstig sein, bleibt aber eine einzelne Runtime-Instanz. |
| CPU-Autoscaling | Auf einem Dedicated-CPU-Plan testen, wenn CPU der Engpass ist | Passe Schwellenwerte anhand echter Last an, weil CPU-Auslastung nicht immer zu Request-Druck oder Queue-Verzögerung passt. |
| Request-Autoscaling | Requests pro Sekunde oder P95-Latenz als Zielwerte für HTTP-Services nutzen | Das ist für Web-Apps oft aussagekräftiger als CPU allein, braucht aber realistischen Traffic und gute Health Checks. |
| Scale to zero | Nur für nicht latenzkritische Services nutzen | Das kann Leerlaufkosten senken, aber Cold Starts und das Verhalten beim ersten Request müssen für Nutzer oder interne Workflows akzeptabel sein. |
Wichtige Limits
Diese App-Platform-Limits solltest du vor Produktion kennen
Die meisten Enttäuschungen entstehen, wenn App Platform wie ein normaler VPS behandelt wird. Das ist sie nicht. Betrachte sie als Managed Runtime mit klaren Grenzen und entscheide dann, ob diese Grenzen Arbeit sparen oder deine App ausbremsen.
| Grenze | Praktische Auswirkung | Besserer Plan |
|---|---|---|
| Lokales Dateisystem | Nur temporär und mit kleinem Dateisystem-Limit | Speichere Uploads, Assets und dauerhaften Zustand in Spaces, Managed Databases oder einem anderen persistenten Dienst. |
| Kein SSH oder SFTP | Container lassen sich nicht wie ein normaler Server debuggen | Investiere in Logs, Metriken, Health Checks, lokale Reproduktion und saubere Container-Images. |
| Build-Limits | Builds haben begrenzte CPU, begrenzten Speicher, begrenzte Disk und Timeouts | Große Monorepos oder schwere Builds brauchen eventuell eine externe CI, die ein fertiges Image pusht. |
| Container-Architektur | Linux-AMD64-Images sind das unterstützte Ziel | Baue und teste Images vor dem Deployment für die richtige Architektur. |
| Networking | Keine direkten IPv6-Service-Verbindungen und keine SMTP-Ports | Nutze IPv4-kompatible Abhängigkeiten und eine API eines Transactional-Email-Anbieters statt rohem SMTP. |
| Compliance | Nicht jeder regulierte Workload passt | Bei strengen Fintech-, PCI-, Netzwerk- oder Audit-Anforderungen solltest du Droplets, Kubernetes oder eine breitere Cloud-Plattform vergleichen. |
Betrieb
Sicherheit und Observability reichen für viele Teams, ersetzen aber keine saubere Planung
App Platform liefert eine solide Basis: automatisches HTTPS, Deployment-Historie, Logs, Health Checks, Alerts, Metriken, private Verbindungsoptionen und verschlüsselte Umgebungsvariablen. Für App-Sicherheit, Secret-Hygiene, Datenbankrechte, Header, Backups und Incident-Abläufe bist du trotzdem selbst verantwortlich.
Solide Plattformbasis
Automatisches HTTPS, DDoS-Abwehr, automatische OS-Patches, Umgebungsvariablen, VPC-Optionen und dedizierte Egress-IPs decken viele typische Sicherheitsanforderungen ab.
Logs und Insights sind nützlich
Nutze App-Platform-Logs, Insights, Alerts, Health Checks und Log Forwarding früh. Sie ersetzen bei diesem Modell einen großen Teil des SSH-basierten Debuggings.
Datenbanken brauchen eine eigene Planung
Development Databases sind bequem, aber Produktion sollte in der Regel Managed Databases nutzen, bei denen Backups, Skalierung, Wartungsfenster und Zugriffskontrollen getrennt geplant werden.
App-Sicherheit bleibt deine Aufgabe
App Platform liefert HTTPS, aber Security Header, Auth, Rate Limiting, Input-Validierung, Secret-Rotation und Dependency-Patches bleiben deine Verantwortung.
Alternativen
DigitalOcean App Platform vs. Droplets, Render, Fly.io und Vercel
Die beste Alternative hängt davon ab, was du vermeiden möchtest. Willst du weniger Betriebsaufwand, vergleiche Managed Platforms. Willst du niedrigere Kosten und volle Kontrolle, vergleiche VPS- oder Kubernetes-Setups.
| Alternative | Nimm sie stattdessen, wenn | Bleib bei App Platform, wenn |
|---|---|---|
| DigitalOcean Droplets | Du brauchst Root-Zugriff, SSH, SFTP, eigene Services, persistente Disks oder den niedrigsten Preis für Always-on-Compute. | Du gibst lieber etwas Kontrolle ab und bekommst dafür Managed Deployments, HTTPS, Logs, Skalierung und weniger Serverpflege. |
| DigitalOcean Kubernetes | Du brauchst Kubernetes-Primitives, eigenes Networking, Service Meshes, Operatoren oder Infrastruktur-Muster mit vielen Services. | Du willst eine einfachere Managed App Runtime und möchtest Kubernetes nicht selbst betreiben. |
| Render or Railway | Dir gefallen deren Developer Experience, Add-on-Modell, Preislogik oder Regionen für deine konkrete App besser. | Dein Stack liegt bereits bei DigitalOcean und du möchtest Datenbanken, Object Storage, Networking und App-Deployments in einem Account halten. |
| Vercel or Netlify | Deine App ist vor allem Frontend-, Edge-, Content- oder Framework-getrieben und profitiert von deren Ökosystem. | Du brauchst Backend-Services, Worker, Jobs und DigitalOcean-Infrastruktur im selben Betriebsmodell. |
| Fly.io or Cloud Run | Du brauchst container-first globale Platzierung, edge-nahe Regionen oder ein anderes Autoscaling- und Container-Modell. | Du möchtest einen klassischeren PaaS-Workflow innerhalb von DigitalOcean. |
GhostlyBridge
Wann ein Droplet der bessere Fallback ist
App Platform nimmt dir Serverarbeit ab, aber auch SSH, SFTP, persistente lokale Disks und Root-Debugging. Wenn das zu deinem normalen Workflow gehört, ist ein DigitalOcean Droplet oft die sauberere Wahl. GhostlyBridge bündelt die tägliche Serverarbeit dann in einem fokussierten Desktop-Workflow.
App Platform nutzen
Wähle App Platform, wenn der Anbieter Build, Deployment, Routing, Skalierung und Runtime-Patches für eine normale Web-App, API, einen Worker oder geplanten Job übernehmen soll.
Droplets mit GhostlyBridge nutzen
Wähle Droplets, wenn du Root-Zugriff, SSH-Workflows, Dateiübertragungen, eigene Services, persistente Disks und einen direkt prüfbaren Server brauchst.
Forschungsnotizen
Aktuelle DigitalOcean-Quellen für diesen Test
Diese Links stehen bewusst weiter unten, damit der Artikel zuerst gut lesbar bleibt. Die praktischen Aussagen oben basieren aber auf der aktuellen Produktseite und Dokumentation zur App Platform. Preise und Limits solltest du vor einer Produktionsmigration immer noch einmal prüfen.
Fazit
DigitalOcean App Platform ist ein sinnvoller Mittelweg für Teams, die Managed Deployments ohne Hyperscale-Komplexität wollen
App Platform ist leicht zu empfehlen für kleine Teams, Agenturen, SaaS-Prototypen, interne Tools, Content-Apps, APIs und Projekte, die bereits DigitalOcean-Datenbanken oder Object Storage nutzen. Sie bringt dich schneller vom Repository in Produktion als ein nackter VPS und bleibt deutlich übersichtlicher als AWS oder Kubernetes.
Ich würde sie meiden, wenn deine App persistenten lokalen Speicher, Shell-Debugging, eigene Kernel, SMTP, reine IPv6-Abhängigkeiten, ungewöhnliche Systempakete oder extrem günstige Always-on-Compute-Kapazität braucht. In solchen Fällen sind ein Droplet, Managed Kubernetes oder ein Anbieter für deine konkrete Runtime meist der bessere Startpunkt.
Häufige Fragen
Ist die DigitalOcean App Platform gut für Produktion geeignet?
Ja, für viele normale Web-Apps, APIs, statische Seiten, Worker und geplante Jobs. Sie ist eine gute Produktionswahl, wenn du Managed Deployment möchtest und die Plattformgrenzen akzeptierst. Weniger geeignet ist sie, wenn dein Produktionsworkflow von SSH, persistentem lokalem Speicher, eigenen Systemservices oder Low-Level-Netzwerkkontrolle abhängt.
Ist App Platform günstiger als ein DigitalOcean Droplet?
Nicht immer. Ein kleines Droplet kann für Always-on-Compute günstiger sein, besonders wenn du Linux ohnehin gut verwaltest. App Platform kann in der Praxis günstiger werden, wenn sie dir Zeit und Risiko bei Deployments, SSL, Logs, Rollbacks, Health Checks und Skalierung abnimmt.
Unterstützt App Platform Docker?
Ja. Du kannst aus einem Dockerfile oder aus Container-Images in unterstützten Registries deployen. Bei schweren Builds ist es oft besser, das Image in der CI zu bauen und das fertige Image zu deployen, um Build-Limits der Plattform zu vermeiden.
Hat App Platform persistenten Speicher?
Nein, für App-Platform-Container gibt es keine persistenten Volumes. Das lokale Dateisystem ist temporär und sollte nur für kleine temporäre Dateien genutzt werden. Für Uploads und Zustand solltest du Spaces, Managed Databases oder einen anderen dauerhaften Speicherdienst nutzen.
Kann App Platform automatisch skalieren?
Ja, aber mit wichtigen Details. App Platform unterstützt manuelle Skalierung und Autoscaling-Optionen. CPU-basiertes Autoscaling erfordert Dedicated-CPU-Pläne, während request-basiertes Autoscaling für geeignete HTTP-Service-Komponenten auf Shared- oder Dedicated-CPU-Plänen funktioniert.
Ist App Platform eine gute Heroku-Alternative?
Sie kann eine gute Alternative sein, besonders wenn dir die DigitalOcean-Preise gefallen und du bereits Datenbanken, Spaces oder die Container Registry dort nutzt. Heroku hat weiterhin ein reifes Add-on-Ökosystem, daher hängt die bessere Wahl von deinem Stack, Supportbedarf und vorhandener DigitalOcean-Infrastruktur ab.
Sollte ich App Platform oder Kubernetes nutzen?
Nutze App Platform, wenn du eine Managed App Runtime und einen einfachen Deployment-Workflow möchtest. Nutze Kubernetes, wenn du Kubernetes-native Kontrolle, Service Meshes, eigenes Networking, Operatoren oder viele Services brauchst, die auf Infrastruktur-Ebene orchestriert werden müssen.