Render Hosting: Kosten, Free-Tier und App-Deploy Schritt für Schritt

Deine App läuft lokal, aber für den nächsten Schritt fehlen Server, Domain und ein verlässlicher Deployment-Prozess? Render nimmt dir einen großen Teil dieser Infrastrukturarbeit ab: Du verbindest ein Git-Repository, hinterlegst Build- und Startbefehl und erhältst eine öffentlich erreichbare Anwendung.

Die wichtige Einschränkung: Der kostenlose Tarif eignet sich für Demos, Lernprojekte und technische Tests, nicht für eine verlässlich erreichbare Produktionsanwendung. Kostenlose Web Services schlafen bei Inaktivität ein, lokale Dateien sind nicht dauerhaft und kostenlose PostgreSQL-Datenbanken laufen nach 30 Tagen ab.

Dieser Guide zeigt, wie Render Hosting funktioniert, was ein produktives Setup tatsächlich kostet und wann eine Alternative besser passt.

Kurz gesagt: Wann ist Render eine gute Wahl?

Render ist eine Platform-as-a-Service, kurz PaaS. Die Plattform betreibt die zugrunde liegenden Server, baut deine Anwendung und stellt sie über HTTPS bereit. Du bleibst für Code, Konfiguration, Daten, Zugänge und die fachliche Funktion der Anwendung verantwortlich.

Render passt gut, wenn du:

• eine API, Web-App oder einen Hintergrundprozess bereitstellen möchtest,
• GitHub, GitLab oder Bitbucket als Ausgangspunkt verwendest,
• keinen eigenen Linux-Server pflegen möchtest,
• Web Service, Worker und PostgreSQL auf einer Plattform bündeln willst,
• mit einer einzelnen Region auskommst,
• und für Produktion mindestens einen kostenpflichtigen Compute-Tarif einplanst.

Render passt weniger gut, wenn du:

• nur eine gewöhnliche Unternehmenswebsite oder einen Blog veröffentlichen möchtest,
• einen dauerhaft schnellen Dienst vollständig kostenlos betreiben willst,
• genaue Kontrolle über Betriebssystem und Netzwerk brauchst,
• Daten zwingend ausschließlich bei einem deutschen oder europäischen Anbieter verarbeiten musst,
• oder mehrere Teammitglieder ohne zusätzlichen Workspace-Tarif einbinden möchtest.

Wenn du noch zwischen Baukasten, klassischem Hosting, PaaS und eigenem Server schwankst, hilft zunächst der Saaspective-Guide „Welches Hosting passt? 7 Fragen für eine klare Entscheidung“.

Schnelle Entscheidung:

• Lernprojekt oder kurzfristige Demo: Free Web Service reicht meist aus.
• Portfolio mit statischen Dateien: Render Static Site oder eine Frontend-Plattform prüfen.
• API oder kleine produktive Web-App: bezahlten Render Web Service einplanen.
• App mit dauerhaften relationalen Daten: Web Service und bezahltes PostgreSQL getrennt kalkulieren.
• Hintergrundaufgaben: Background Worker statt Web Service verwenden.
• Mehrere Teammitglieder: Pro-Workspace in die Gesamtkosten aufnehmen.
• Volle Serverkontrolle: Cloud-VM oder VPS prüfen.

Welchen Render-Service brauchst du?

„Render Hosting“ ist kein einzelnes Produkt. Die richtige Auswahl hängt davon ab, was dein Code tatsächlich ausführt.

Für ein Express-, Django-, FastAPI-, Rails- oder vergleichbares Backend ist normalerweise ein Web Service richtig. Ein rein statisch exportiertes Frontend gehört dagegen auf eine Static Site.

Render unterstützt Node.js/Bun, Python, Ruby, Go, Rust und Elixir nativ. Andere Laufzeiten wie Java, PHP oder .NET können über ein Docker-Image bereitgestellt werden. Falls Container für dich noch neu sind, erklärt „Docker einfach erklärt“, was ein Image löst und welche Verantwortung trotzdem bleibt.

Was Render beim Hosting übernimmt – und was nicht

Ein Render Web Service läuft in einer von Render verwalteten, containerisierten Umgebung. Bei einem verbundenen Git-Repository kann Render Änderungen automatisch bauen und deployen. Dazu kommen eine onrender.com-Adresse, verwaltete TLS-Zertifikate, eigene Domains, Logs, Health Checks und Rollbacks.

Render übernimmt Bereitstellung, Build-Infrastruktur, eingehendes HTTPS und Plattformwartung. Du übernimmst funktionierenden Anwendungscode, sichere Authentifizierung, Datenmodell, Migrationen, Backups, Monitoring und Kostenkontrolle.

Wer Betriebssystem, Firewall, Paketupdates und Netzwerk selbst steuern möchte, braucht eher einen Cloud-Server. Der Saaspective-Artikel „Hetzner Cloud einfach erklärt“ zeigt, welche zusätzliche Verantwortung damit entsteht.

Was Render Hosting aktuell kostet

Render trennt drei Kostenarten:

1. den Workspace-Tarif,
2. die Rechenleistung jedes einzelnen Dienstes,
3. verbrauchsabhängige Posten wie Bandbreite, Speicher und zusätzliche Build-Minuten.

Ein kostenloser Hobby-Workspace bedeutet deshalb nicht automatisch, dass alle darin betriebenen Services kostenlos sind.

Compute wird laut Render sekundengenau anteilig abgerechnet. Ein Dienst, der nur einen Teil des Monats läuft, verursacht daher nicht automatisch den vollen Monatsbetrag.

Für eine kleine produktive Anwendung mit eigenem Web Service und PostgreSQL entstehen aber mindestens zwei Compute-Posten. Die Aussage „Render kostet nur sieben Dollar“ greift zu kurz, sobald eine Datenbank, ein Worker oder ein Team-Workspace hinzukommt.

Die Preise werden in US-Dollar ausgewiesen. Zusätzlich können anwendbare Steuern berechnet werden. Maßgeblich sind die beim Kauf angezeigten Konditionen und die Rechnung.

Ist Render wirklich kostenlos?

Ja, aber nur innerhalb klarer Grenzen. Für eine Demo oder ein Lernprojekt kann der kostenlose Tarif nützlich sein. Für eine öffentlich beworbene App oder einen geschäftskritischen Dienst ist er zu unzuverlässig.

Die wichtigsten Grenzen des kostenlosen Web Service

• Nach 15 Minuten ohne eingehenden HTTP- oder WebSocket-Verkehr fährt Render den Dienst herunter.
• Die nächste Anfrage startet ihn wieder. Das Aufwachen dauert laut Anbieter ungefähr eine Minute.
• Pro Workspace stehen monatlich 750 kostenlose Instanzstunden bereit.
• Mehrere kostenlose Web Services teilen sich dieses Kontingent.
• Horizontale Skalierung, persistente Disks, Shell-Zugriff und One-off Jobs fehlen.
• Änderungen am lokalen Dateisystem gehen bei Neustart, Redeploy oder Spin-down verloren.
• Ausgehende Verbindungen über die üblichen SMTP-Ports 25, 465 und 587 sind blockiert.
• Ungewöhnlich hoher, vom Dienst initiierter Internetverkehr kann zur Sperrung der kostenlosen Instanz führen.
• Ist der Service eingeschlafen, beantwortet Render /robots.txt automatisch mit einer vollständigen Crawling-Sperre.

Gerade der letzte Punkt macht den Free-Tarif für eine indexierbare Website problematisch: Während der Dienst schläft, können Suchmaschinen einen Disallow-Hinweis erhalten.

Wenn du eine Zahlungsmethode hinterlegt hast und enthaltene Bandbreite oder Build-Minuten überschreitest, kann Render Mehrverbrauch berechnen. Ohne Zahlungsmethode werden betroffene Dienste oder neue Builds stattdessen für den restlichen Abrechnungszeitraum deaktiviert.

Die kostenlose PostgreSQL-Datenbank ist nicht dauerhaft

Die Free-Datenbank hat derzeit 1 GB Speicher und läuft 30 Tage nach ihrer Erstellung ab. Danach bleiben 14 Tage für ein Upgrade. Erfolgt keines, löscht Render die Datenbank. Automatische Backups und Managed Connection Pooling sind im kostenlosen Plan nicht enthalten.

Damit eignet sie sich für Tutorials, zeitlich begrenzte Demos und Tests mit entbehrlichen Daten. Sie eignet sich nicht für Kundendaten, Bestellungen, dauerhafte Nutzerkonten oder andere Daten, deren Verlust Folgen hätte.

App auf Render deployen: sieben entscheidende Schritte

1. Anwendung vorbereiten

Notiere Root-Verzeichnis, Laufzeitversion, Installations- und Build-Befehl, Startbefehl, Umgebungsvariablen, Datenbankmigrationen und einen Health-Check-Pfad. API-Schlüssel und Passwörter gehören in geschützte Umgebungsvariablen, nicht ins Repository.

2. Auf dem bereitgestellten Port lauschen

Render stellt Web Services die Umgebungsvariable PORT bereit. Die Anwendung muss auf diesem Port und auf 0.0.0.0 lauschen. Ein fest verdrahtetes localhost:3000 ist eine häufige Ursache für fehlgeschlagene Deployments.

3. Repository verbinden

Wähle im Render-Dashboard New, danach Web Service sowie Git-Anbieter, Repository und Branch. Bei verbundenen Git-Zugangsdaten kann Render nach jedem Push automatisch neu deployen.

4. Region, Build und Start konfigurieren

Für Nutzer in Deutschland ist Frankfurt meist der naheliegende Startpunkt, sofern Anwendung und Datenbank dort gemeinsam laufen. Hinterlege Runtime oder Docker-Quelle, Root Directory, Build Command, Start Command, Environment Variables und Health Check Path.

5. Speicherstrategie festlegen

Das normale Dateisystem ist flüchtig. Hochgeladene Bilder, SQLite-Datenbanken oder erzeugte Dokumente können bei Redeploy oder Neustart verschwinden. Dauerhafte Daten gehören je nach Typ in PostgreSQL, Key Value, einen Objektspeicher oder eine persistente Disk.

6. Build und Kernfunktionen testen

Prüfe Build, Prozessstart, Port, Secrets, Datenbankverbindung, Login, Uploads, Hintergrundaufgaben und Fehlerprotokollierung. Teste nicht nur die Startseite, sondern die Wege, deren Ausfall echte Folgen hätte.

7. Domain, Health Check und Rückweg einrichten

Render stellt zunächst eine onrender.com-Adresse bereit. Eigene Domains erhalten automatisch verwaltete TLS-Zertifikate. Wenn DNS-Einträge noch ungewohnt sind, zeigt „DNS einfach erklärt“, wie Domain, Hosting und HTTPS zusammenhängen.

Ein HTTP-Health-Check sollte mehr prüfen als „der Prozess läuft“. Für eine API kann eine kleine, schnelle Datenbankabfrage sinnvoll sein. Teste außerdem einen Rollback. Ein Code-Rollback setzt Datenbankänderungen, persistente Disks, Domains oder die gesamte aktuelle Konfiguration nicht automatisch zurück.

Dateien, Backups und Skalierung: die wichtigste Architekturgrenze

Eine persistente Disk bindet einen Dienst an eine einzelne Instanz. Services mit angehängter Disk lassen sich nicht auf mehrere Instanzen skalieren, und Deployments sind nicht mehr ohne Unterbrechung möglich. Nur Dateien unter dem konfigurierten Mount-Pfad bleiben erhalten.

Render erstellt für persistente Disks täglich Snapshots, die mindestens sieben Tage verfügbar sind. Bei selbst betriebenen Datenbanken ersetzt ein Dateisystem-Snapshot jedoch kein anwendungskonsistentes Datenbank-Backup. Für produktive PostgreSQL-Datenbanken solltest du logische Exporte und einen echten Restore testen.

Der Hobby-Workspace bewahrt Logs und Servicemetriken derzeit sieben Tage auf. Längere Aufbewahrung oder externe Alarmierung muss separat geplant werden.

Wenn die Anwendung nach dem Deploy langsam ist, sollte nicht automatisch der Tarif vergrößert werden. Der Saaspective-Vergleich „CDN oder schnelleres Hosting?“ zeigt, wie du Netzwerk, Backend und Frontend als getrennte Engpässe misst.

Datenschutz: Reicht die Region Frankfurt für die DSGVO?

Render bietet Frankfurt als Region für Web Services, Datenbanken und andere regionale Dienste an. Für statische Websites lässt sich dagegen keine einzelne Region wählen, weil sie über ein globales CDN ausgeliefert werden.

Die Wahl von Frankfurt ist für kurze Wege und eine regionale Datenbank sinnvoll. Sie bedeutet aber nicht automatisch, dass jede Form der Verarbeitung ausschließlich in Deutschland stattfindet. Kontodaten, Support, Logs, Unterauftragnehmer und andere Plattformprozesse müssen gesondert geprüft werden.

Render stellt ein Data Processing Addendum bereit, das die DSGVO ausdrücklich umfasst und auf eine Liste autorisierter Unterauftragnehmer verweist. Für ein deutsches Unternehmen gehören mindestens diese Fragen in die Prüfung:

• Sind Anwendung und Datenbank in Frankfurt angelegt?
• Welche personenbezogenen Daten verarbeitet die App?
• Ist das Render-DPA abgeschlossen und dokumentiert?
• Welche Unterauftragnehmer sind beteiligt?
• Welche Daten verlassen die gewählte Region?
• Wie werden Daten exportiert und gelöscht?
• Wer kann auf Secrets, Logs und Datenbanken zugreifen?
• Gibt es ein getestetes Backup außerhalb des Live-Systems?

„Region Frankfurt“ ist ein technisches Merkmal, keine vollständige Datenschutzbewertung. Maßgeblich sind der konkrete Datenfluss, Vertrag, Unterauftragnehmer und die Schutzbedürftigkeit der Daten. Das ersetzt keine Rechtsberatung.

Für wen lohnt sich Render?

Solo-Entwickler und kleine technische Teams: Wenn eine App aus Web Service, Worker und PostgreSQL besteht, bietet Render einen übersichtlichen Weg von Git zur laufenden Anwendung.

Demos und Lernprojekte: Der Free-Tarif ist nützlich, wenn lange Startzeiten und ein Ablauf der Testdatenbank akzeptabel sind.

Produktionsanwendungen mit kleinem Budget: Ein bezahlter Web Service beginnt günstig. Mit Datenbank, Worker, Speicher, Bandbreite und Teamzugang steigt der Gesamtpreis jedoch serviceweise.

Nicht sinnvoll als reine Free-Tier-Produktion: Cold Starts, fehlende Backups, eine auslaufende Datenbank und flüchtige Dateien sind keine tragfähige Basis für zahlende Kunden.

Nicht ideal bei voller Infrastrukturkontrolle: Wer spezielle Netzwerkregeln, eigene Systempakete oder genaue VM-Optimierung braucht, wird mit einer Cloud-VM flexibler sein. Dafür übernimmt das Team deutlich mehr Betriebsarbeit.

Render oder eine Alternative?

Keine Plattform ist allgemein die beste. Die passende Wahl folgt der Anwendung, dem Kostenmodell und der Betriebsbereitschaft des Teams.

Klare Entscheidung: Welche Render-Variante passt?

Nimm den kostenlosen Web Service, wenn du eine Technik ausprobieren oder eine zeitlich begrenzte Demo zeigen möchtest. Verwende dort keine unersetzlichen Daten.

Nimm einen bezahlten Web Service, wenn die Anwendung jederzeit ohne langen Kaltstart erreichbar sein soll. Ergänze einen Health Check, Kostenwarnungen und einen getesteten Rollback.

Ergänze bezahltes Render Postgres, wenn die App dauerhafte relationale Daten verarbeitet. Verlasse dich nicht nur auf die integrierte Wiederherstellung, sondern exportiere regelmäßig logische Backups und teste den Restore.

Rechne den Pro-Workspace ein, sobald mehrere Personen auf produktive Dienste zugreifen oder Audit-Logs und weitere Teamfunktionen gebraucht werden. Der Compute-Preis allein beschreibt dann nicht mehr die Gesamtkosten.

Wähle eine Alternative, wenn ein statisches oder stark Next.js-zentriertes Frontend dein Hauptfall ist, du mehrere Regionen aktiv betreiben willst oder dein Team einen eigenen Server zuverlässig administrieren kann.

Render ist am stärksten, wenn du eine gewöhnliche Web-App schnell veröffentlichen möchtest und weniger Infrastruktur bedienen willst. Es ist kein Ersatz für Datenstrategie, Monitoring, Backups oder Kostenkontrolle. Wer diese vier Punkte vor dem ersten produktiven Deploy klärt, bekommt eine bequeme Plattform – ohne die typischen Free-Tier-Überraschungen.