Renders Preisänderung im April 2026: keine Pro-Seat-Gebühr mehr, aber deutlich weniger Bandbreite inklusive
Am 23. April 2026 hat Render seine Pro-Seat-Preise durch eine pauschale Workspace-Gebühr ersetzt: 0 $ im Monat für Hobby, 25 $ im Monat für Pro, 499 $ im Monat für Scale, bestätigt direkt in Renders eigener Preisankündigung. Bestehende Workspaces hatten bis zum 1. August 2026 Zeit, auf die neuen Pläne umzusteigen. Im selben Zug hat Render die in diesen Plänen inkludierte Bandbreite deutlich gekürzt: Hobbys inkludiertes Egress fiel von 100 GB auf 5 GB, und Berichte über die Änderung beschreiben eine vergleichbare Kürzung bei Pro, wobei Overage jetzt pauschal mit 0,15 $ pro Gigabyte abgerechnet wird statt wie bisher in 100-GB-Blöcken. Renders eigene Ankündigung besagt, dass 75 % der zahlenden Kunden unter der neuen Struktur eine sinkende oder gleichbleibende Rechnung sehen würden. Für eine bestimmte, verbreitete Art von Workload läuft die Rechnung allerdings in die andere Richtung, und es lohnt sich, genau nachzuvollziehen, warum.
Was sich tatsächlich geändert hat, in Renders eigenen Worten
Die Schlagzeile ist die Änderung, mit der Render selbst vorangegangen ist: keine Pro-Seat-Gebühr mehr. Im alten Modell zahlte ein Pro-Workspace etwa 19 bis 29 $ pro Teammitglied und Monat, was bedeutete, dass allein die Basis-Plattformgebühr eines Fünf-Personen-Teams 95 bis 145 $ betragen konnte, bevor überhaupt ein einziger Service lief. Im neuen Modell wird das durch eine pauschale Gebühr pro Workspace ersetzt, 25 $ im Monat für Pro, unabhängig davon, ob der Workspace eine oder zwanzig Personen hat. Für jedes Team, das größer ist als ein einzelner Entwickler, ist dieser Teil der Änderung eine klare Verbesserung, und es ist der Teil, der Renders eigene Behauptung stützt, dass die meisten zahlenden Kunden besser oder gleich gut dastehen.
Die zweite Änderung erhielt deutlich weniger Aufmerksamkeit: die inkludierte Bandbreite pro Plan sank stark. Hobbys Egress-Kontingent fiel von 100 GB auf 5 GB, eine Kürzung um das 20-Fache. Berichte über den Pro-Plan beschreiben eine ähnlich drastische Reduktion, auf 25 GB inklusive, wobei das genaue vorherige Kontingent in der Berichterstattung über die Änderung uneinheitlich angegeben wird (manche Berichte setzen das alte Pro-Kontingent bei 100 GB an, andere höher), sodass die genaue “Vorher”-Zahl hier eher als berichtet denn als unabhängig bestätigt zu behandeln ist. Was über alle Berichte hinweg konsistent ist, einschließlich Renders eigener aktueller Preisseiten, ist die “Nachher”-Zahl: 25 GB inklusive bei Pro, 1 TB bei Scale, und pauschal 0,15 $ pro Gigabyte für alles darüber.
Warum hat Render die inkludierte Bandbreite gekürzt und die Pro-Seat-Gebühr abgeschafft?
Diese beiden Änderungen wirken unabhängig voneinander, sind es aber nicht. Eine Pro-Seat-Gebühr ist eine Rechnung, die mit der Anzahl der Personen skaliert, die das Produkt nutzen, was fast nichts damit zu tun hat, was es Render tatsächlich kostet, die Infrastruktur eines Kunden zu betreiben. Egress, die Daten, die eine laufende App an ihre Nutzer zurücksendet, ist ein realer, gemessener Kostenpunkt, den Render selbst an seine eigenen Upstream-Anbieter zahlt, und er skaliert mit genau einer Sache: wie viel Traffic die App eines Kunden tatsächlich bedient. Der Wechsel von “pro Person abrechnen” zu “pro tatsächlich genutztem Gigabyte abrechnen” ist, mechanisch betrachtet, ein Schritt näher an Renders eigener realer Kostenstruktur und weg von einer Zahl (Teamgröße), die immer nur ein grober Näherungswert für Nutzung war.
Das ist ein nachvollziehbarer geschäftlicher Grund für die Änderung, und er passt zu Renders breiterer Entwicklung: Das Unternehmen sammelte im Februar 2026 100 Millionen Dollar bei einer berichteten Bewertung von 1,5 Milliarden Dollar ein, bei mehr als 100 % Wachstum im Jahresvergleich, eine Finanzierungsgeschichte, die von einer Kostenstruktur abhängt, die vorhersagbar mit der Nutzung skaliert, statt einer, bei der einige wenige Kunden mit hohem Traffic sich stillschweigend auf einem pauschalen, seat-basierten Plan subventionieren, der für eine andere Art von Workload kalkuliert war. Nichts davon macht die Änderung an sich schlecht. Es bedeutet aber, dass die Kunden, die der Nachteil am stärksten trifft, eine bestimmte, identifizierbare Gruppe sind: Workloads mit echter nachhaltiger Bandbreitennutzung, Video, Datei-Downloads, API-Antworten mit großen Payloads, Webhooks, die in hoher Frequenz feuern, die früher bequem in ein großzügiges Pauschalkontingent passten und jetzt auf einen Zähler treffen.
Was das für eine echte Workload kostet
Nimm ein ziemlich gewöhnliches Pro-Tier-Setup: ein Web-Service, ein Background-Worker, beide in Standardgröße, plus eine kleine verwaltete Postgres-Datenbank. Bevor überhaupt Egress mitgezählt wird, liegt das unter den neuen Preisen bei etwa 95 $ im Monat, Workspace-Gebühr inklusive. Bei geringem Traffic, unterhalb des inkludierten 25-GB-Kontingents, ist das die gesamte Rechnung, und das ist eine echte Verbesserung gegenüber dem alten Pro-Seat-Preismodell für ein Team von mehr als ein oder zwei Personen.
Ab diesem Punkt bewegt sich die Zahl schnell. Bei 500 GB monatlichem Egress, eine angemessene Zahl für eine App, die Bilder, Video-Thumbnails oder eine moderate Menge API-Traffic für ein paar tausend Nutzer bedient, beträgt das Overage 475 GB über dem inkludierten Kontingent, zu 0,15 $ pro Gigabyte sind das etwa 71 $ zusätzlich zur Basis, für eine Gesamtsumme nahe 166 $ im Monat. Bei 1 TB monatlichem Egress steigt das Overage auf rund 150 $, was die Gesamtsumme über 245 $ treibt. Bei 2 TB, eine Workload, die für eine medienintensive Consumer-App nicht ungewöhnlich ist, nähert sich allein die Egress-Position 300 $, mehr als das Dreifache der Basis-Plattformgebühr. Das Muster ist eindeutig: Bandbreite, nicht Compute oder die Workspace-Gebühr, wird zur dominierenden Position auf der Rechnung für alles jenseits einer leicht frequentierten App, und sie steigt weiter ohne Obergrenze, bis ein Kunde auf den 499-$-Scale-Plan mit seinem 1-TB-Kontingent wechselt.
Der Teil, der zum Nachdenken anregt: Nichts davon erfordert, dass ein Team eine ungewöhnliche Entscheidung trifft. Video, Bilder oder große JSON-Payloads zu bedienen, oder einfach eine beliebte App zu haben, ist kein exotisches Verhalten, es ist ein großer Teil dessen, was Webanwendungen tatsächlich tun. Ein Preismodell, das kleinen Teams nach Kopfzahl entgegenkommt und für jeden mit echtem nachhaltigem Traffic deutlich unfreundlicher ist, ist ein spezifischer, bewusster Trade-off, keine universelle Verbesserung, und Renders eigene 75-Prozent-Darstellung passt dazu: Sie beschreibt den medianen Kunden, nicht den langen Rand von Kunden, deren Workloads genau die Art sind, die echte Bandbreite erzeugt.
Was ein Festpreis ohne Egress-Zähler anders macht
Railyards Preismodell hat überhaupt keine Bandbreiten-Position, gemessen oder sonst wie. Der 19-Dollar-Pro-Plan und der 49-Dollar-Team-Plan sind pauschal pro Team, unabhängig davon, wie viel Traffic die Apps auf diesen Servern tatsächlich bedienen. Das ist aus einem strukturellen Grund möglich, nicht aus Großzügigkeit: Die Server selbst laufen im eigenen Cloud-Account des Kunden, und Bandbreite wird vom Cloud-Anbieter (DigitalOcean, Hetzner, Vultr) direkt an den Kunden abgerechnet, zum Tarif dieses Anbieters, der bei den meisten Anbietern ein deutlich größeres Bandbreitenkontingent in den Serverpreis einschließt und historisch bei weitem nicht an einen marginalen Satz von 0,15 $ pro Gigabyte heranreicht, sobald das eigene Kontingent eines Servers aufgebraucht ist. Railyard rührt diese Rechnung nie an, hat keinen Aufschlag darauf, und hat nichts zu messen, weil der Traffic nie durch Infrastruktur läuft, die Railyard überhaupt besitzt.
Das ist derselbe architektonische Gabelpunkt, der in jedem Vergleich zwischen einer verwalteten Plattform und einer BYO-Server-Lösung auftaucht: Eine Plattform, die den Compute selbst betreibt, muss die Ressourcen bepreisen, für die sie tatsächlich zahlt, was für eine bandbreitenintensive Workload irgendwann bedeutet, Bandbreite zu messen, weil das ein echter, variabler Kostenpunkt ist, den die Plattform im Namen des Kunden absorbiert. Eine Plattform, die den Compute nicht betreibt, hat keine solchen Kosten einzutreiben, also gibt es nichts zu messen. Keiner der beiden Ansätze ist ein Trick. Renders Egress-Kosten sind echtes Geld, das Render irgendwo stromaufwärts zahlt, und einen Teil davon von den Kunden einzutreiben, die den Traffic erzeugen, ist eine vertretbare, möglicherweise sogar ehrlichere Preisentscheidung, als es in einer Pauschale zu verstecken, die andere Kunden am Ende subventionieren. Die ehrliche Einordnung ist, dass die beiden Modelle für unterschiedliche Workloads optimiert sind: Eine Plattform mit gemessenem Egress ist eine faire, gute Wahl für ein Team mit moderatem, vorhersehbarem Traffic, das von den niedrigeren seat-basierten Kosten profitiert; ein pauschaler Teampreis mit direkt vom Cloud-Anbieter abgerechnetem Egress passt besser, sobald der Traffic groß genug ist, dass ein Pro-Gigabyte-Zähler die Rechnung dominieren würde.
Die eigentliche Lektion
Render hat hier nichts Täuschendes gemacht. Das Unternehmen hat die Änderung veröffentlicht, ein echtes Übergangsfenster eingeräumt und mit dem Teil der Änderung vorangegangen, der für die meisten Kunden ein unzweifelhafter Gewinn ist. Der Teil, den man vor der Anmeldung oder vor der Budgetierung einer Verlängerung kennen sollte, ist der Teil, der nicht die Schlagzeile bekam: Eine Workload mit echter, nachhaltiger Bandbreite wird jetzt pro Gigabyte abgerechnet, ohne Obergrenze unterhalb der nächsten Plan-Stufe, als Ersatz für ein Kontingent, das über den größten Teil von Renders Geschichte großzügig genug war, um nicht darüber nachzudenken. Wer eine bandbreitenintensive App auf Render betreibt, sollte die Rechnung für seinen tatsächlichen Traffic durchgehen, bevor er annimmt, dass der neue, freundlicher wirkende Basispreis die ganze Geschichte erzählt.
FAQ
Wann hat Render seine Preise geändert? Render ist am 23. April 2026 zu einem pauschalen Workspace-Gebührenmodell übergegangen, wobei bestehende Workspaces bis zum 1. August 2026 migrieren mussten.
Wie viel Bandbreite inkludiert Render jetzt? Die neuen Pläne inkludieren 5 GB bei Hobby, 25 GB bei Pro und 1 TB bei Scale, deutlich weniger als die Kontingente vor April 2026, mit Overage abgerechnet zu 0,15 $ pro Gigabyte.
Sind Renders Preise gestiegen oder gesunken? Beides, abhängig von der Workload. Der Wegfall der Pro-Seat-Gebühr senkt die Rechnung für die meisten Teams, besonders größere. Die Kürzung der inkludierten Bandbreite erhöht die Rechnung für jede Workload mit echtem nachhaltigem Traffic, da Egress jetzt ab einem deutlich kleineren inkludierten Kontingent gemessen wird.
Berechnet Railyard für Bandbreite? Nein. Railyards Server laufen im eigenen Cloud-Account des Kunden, sodass Bandbreite direkt vom Cloud-Anbieter zu dessen Tarif abgerechnet wird, nicht von Railyard gemessen oder aufgeschlagen.
Quellen
- Render: “Better pricing for fast-growing teams”, Renders eigene Ankündigung, geprüft im Oktober 2026, bestätigt die 0-$/25-$/499-$-Workspace-Stufen, inkludierte Bandbreite von 5 GB/25 GB/1 TB, den 0,15-$/GB-Overage-Satz und die 75-Prozent-Kunden-Behauptung
- Berichterstattung über die Hobby-Bandbreitenkürzung im April 2026, darunter Render’s April 2026 Egress Cut From 100GB to 5GB on Hobby
- Berichterstattung über den geschäftlichen Kontext hinter der Änderung, einschließlich Renders Finanzierungsrunde vom Februar 2026, in Render’s $1.5B Valuation Hides a $0.15/GB Question
- Railyards eigene Preisseite für aktuelle Details zum pauschalen Teamplan
Vergleiche die Modelle direkt: Railyard mit Render vergleichen, oder sieh dir wie Railyards Festpreismodell funktioniert auf Servern an, die du schon besitzt.