Render behalten
- Webdienst plus Datenbank. Kein Mobile, kein SSH.
Render Alternative, wenn du mehr als einen Webdienst auslieferst
Render nimmt dir den Server für Webdienste weitgehend ab. Das ist der Job. SSH, ein eigenes Netz, ein iOS-Build – das ist ein anderer Job, und den macht Render nicht.
- Du kommst per SSH auf die Maschine, oder wir betreiben sie und du trotzdem
- Dieselbe Pipeline kann die App in den Store schieben, nicht nur den Webdienst
PaaS-Komfort oder Zugang zur Box
Render ist zu wenig
- Du brauchst die Maschine, oder Web und App sollen denselben Merge sehen.
Render sitzt zwischen Heroku und einem VPS: bequem, aber die Maschine bleibt fremd. Sobald du Logs auf der Box selbst sehen oder eine App signieren willst, endet der Komfort.
Render-Dienste gegen Zugang zur Box
Render ist bequem für Webdienste. SSH und Store sind andere Produkte.
| Kriterium |
Application Platform
|
Render
|
|---|---|---|
| Web Services und APIs deployen | Vollständig abgedeckt: NestJS, Laravel, FastAPI und Frontends über vorbereitete Pipelines | Vollständig abgedeckt: Kernprodukt, ausgereift und mit guter Entwicklererfahrung |
| Cron Jobs und Hintergrunddienste | Vollständig abgedeckt: Laufen als Container auf deinem Server, konfiguriert im Projekt | Vollständig abgedeckt: Cron Jobs und Background Worker als eigene Dienstarten |
| Datenbanken | Vollständig abgedeckt: Werden auf deinem Server eingerichtet, inklusive Backups | Vollständig abgedeckt: Verwaltete Datenbanken als Teil der Plattform |
| Eigene Server nutzen | Vollständig abgedeckt: Eigener Server per SSH oder Managed Server der Plattform | Nicht angeboten: Nicht vorgesehen, Ausführung in der Render-Infrastruktur |
| Projekt-Setup aus Templates | Vollständig abgedeckt: Next.js, NestJS, Laravel, FastAPI, Flutter, Expo, Astro und Hugo als fertige Projektbasis | Teilweise abgedeckt: Vorlagen zum Deployment bestehender Projekte, kein Projekt-Scaffolding |
| Konfiguration im Repository | Vollständig abgedeckt: Konfiguration in Git für Umgebungen und Deployments, GitLab-CI-Konfiguration frei anpassbar | Vollständig abgedeckt: Infrastructure as Code über eine YAML-Datei im Repository |
| Mobile Apps bauen | Vollständig abgedeckt: Flutter, Expo sowie native iOS- und Android-Projekte inklusive Build-Umgebung | Nicht angeboten: Nicht Teil des Produkts |
| App Store und Play Store veröffentlichen | Vollständig abgedeckt: Metadaten, Screenshots und Versionen über Fastlane aus der Plattform heraus | Nicht angeboten: Nicht Teil des Produkts |
| Remote-Entwicklungsumgebungen | Vollständig abgedeckt: Ubuntu-Workspaces mit VS Code, JetBrains, RDP und VNC. iOS-Builds auf macOS-Geräten der Pipeline | Nicht angeboten: Nicht Teil des Produkts |
| Globales Edge-Netzwerk / CDN | Teilweise abgedeckt: Reverse-Proxy und SSL pro Server; kein eigenes globales Edge-Netz | Vollständig abgedeckt: CDN für statische Inhalte, mehrere Regionen wählbar |
| Standort der Verarbeitung | Vollständig abgedeckt: Betrieb in der EU, Auftragsverarbeitungsvertrag, Server frei wählbar | Teilweise abgedeckt: US-Anbieter, Regionen wählbar, Verarbeitung nach US-Recht |
Grün bedeutet vollständig abgedeckt, gelb teilweise, grau nicht vorgesehen. Render ist im PaaS-Bereich stark – der Unterschied liegt im Umfang der abgedeckten Kette.
Stand: 9. September 2026. Grundlage sind die öffentlich dokumentierten Funktionsumfänge der genannten Anbieter. Angaben können sich ändern; maßgeblich ist die jeweils aktuelle Darstellung des Anbieters. Logos sind Marken der jeweiligen Rechteinhaber und dienen nur der Zuordnung.
Render-Stärken
- Komfortables PaaS Render nimmt dir den Server weitgehend ab. Wer das sucht und kein Mobile braucht, bleibt dort richtig.
Kostenmodell
Render staffelt nach Instanz und Traffic. Siehe Render Pricing.
Pipeline für Kunden-App
test
build
publish
release
Von Render zur Application Platform wechseln
Der Umzug läuft schrittweise, dein Repository bleibt die Grundlage.
-
Server verbinden
Binde einen eigenen Server per SSH an oder buche einen Managed Server. Das Grundsetup mit Docker, Reverse-Proxy, SSL und Backups entsteht automatisch.
-
Projekt anlegen
Lege dein Projekt im Assistenten an und wähle den Stack. Repository, Struktur und CI/CD-Pipeline entstehen mit.
-
Dienste und Datenbanken übernehmen
Übertrage Web Services, Cron Jobs und Datenbanken nacheinander. Umgebungsvariablen und Secrets pflegst du zentral im Projekt.
-
Domain umstellen
Domain und Zertifikate gehören zum Setup. Sobald die Pipeline grün ist, zeigst du den DNS-Eintrag um.
Häufige Fragen
Ist die Application Platform ein direkter Render-Ersatz?
Für Web Services, Hintergrundjobs und Datenbanken ja, und darüber hinaus deckt sie mehr ab. Ein globales Edge-Netzwerk für statische Inhalte bringt sie nicht mit – dafür bleibt ein vorgeschaltetes CDN sinnvoll.
Muss ich mich künftig um Server kümmern?
Nur so weit, wie du möchtest. Beim Managed Server übernimmt die Plattform Einrichtung und Wartung. Beim eigenen Server richtet sie Docker, Datenbanken, Reverse-Proxy, SSL, Firewall und Backups ein, der Betrieb bleibt bei dir, per SSH einsehbar.
Was passiert mit meiner render.yaml?
Die Datei selbst übernehmen wir nicht, das Prinzip schon. Umgebungen und Deployments liegen ebenfalls als Konfiguration im Git-Verlauf, ergänzt um eine GitLab-CI-Pipeline im Repository. Den Zuschnitt der Stages bestimmst du selbst.
Wie unterscheiden sich die Kosten?
Render rechnet pro Dienst und Ressourcengröße ab, plus Datenbanken und Bandbreite. Bei uns zahlst du Plattform und Server. Kommen viele kleine Dienste zusammen, ist ein gemeinsamer Server oft günstiger. Details stehen auf der Preisseite.
Warum ist der Verarbeitungsstandort relevant?
Render ist ein US-Anbieter, was sich vertraglich regeln lässt, in Ausschreibungen aber oft Rückfragen erzeugt. Die Application Platform wird in der EU betrieben, mit Auftragsverarbeitungsvertrag, und du wählst selbst, wo deine Server stehen.
Webdienst lassen, den Rest nicht
Render kann den HTTP-Dienst weiter machen. Die App und die Box müssen das nicht.