Render, hosting PaaS z abonamentem za instancje

Render, hosting PaaS z abonamentem za instancje

Render bierze repozytorium z GitHuba, buduje je i uruchamia jako usługę z certyfikatem TLS, a bazę Postgres podaje jako osobny zasób. Rozlicza się inaczej niż Railway czy Fly.io: płacisz abonament za plan workspace plus stałą stawkę za wybrany rozmiar instancji, a nie za faktycznie zużyte cykle procesora.

Co Render właściwie robi

Render obsługuje kilka typów zasobów i różnice między nimi decydują o rachunku. Static sites to statyczne pliki na CDN, rozliczane wyłącznie transferem i minutami budowania. Web services przyjmują ruch z internetu. Private services odpowiadają tylko wewnątrz sieci prywatnej regionu. Background workers nie mają portu i po prostu chodzą. Cron jobs uruchamiają się według wyrażenia cron i płacisz za minuty ich pracy. Do tego dochodzą Render Postgres, Render Key Value w wariancie zgodnym z Redisem oraz Workflows, czyli trwałe wykonywanie zadań.

Natywne środowiska uruchomieniowe to node, python, elixir, go, ruby i rust. Poza nimi masz docker dla obrazu budowanego z pliku Dockerfile oraz image dla obrazu pobieranego z rejestru. Regiony to oregon, ohio, virginia, frankfurt i singapore, a raz wybranego regionu nie zmienisz dla istniejącej usługi.

Platforma sama robi rzeczy, które w innym modelu musiałbyś złożyć ręcznie: certyfikaty TLS dla domen własnych, wdrożenia bez przerwy w działaniu, health checki, podgląd zmian z pull requesta, prywatną sieć między usługami w tym samym regionie oraz SSH do działającej instancji. Jeśli szukasz tego samego na własnym serwerze, punktem wyjścia jest zwykle reverse proxy w rodzaju Caddy i sporo pracy własnej.

Czego Render nie robi. System plików usługi jest ulotny i po każdym wdrożeniu, restarcie albo uśpieniu wraca do stanu z obrazu. Trwałość dostajesz przez dysk (disk) za 0,25 USD za GB miesięcznie albo przez bazę. Usługa z podpiętym dyskiem nie skaluje się poziomo, więc dysk i autoskalowanie wykluczają się wzajemnie. Nie ma też funkcji na brzegu sieci w stylu edge functions ani wariantu instalowanego u siebie.

Co Render publikuje jako otwarte oprogramowanie

Sama platforma jest zamknięta. Otwarte jest tylko oprzyrządowanie klienckie i tu licencje rozjeżdżają się między repozytorium a rejestrami pakietów, więc sprawdziłem trzy źródła osobno.

Klient wiersza poleceń żyje w repozytorium render-oss/cli, plik LICENSE zawiera pełny tekst Apache 2.0, a bieżące wydanie to v2.24.0 z 19 sierpnia 2026 roku. Dostawca dla Terraforma, render-oss/terraform-provider-render, też jest na Apache 2.0, wersja 1.9.1 opublikowana w rejestrze Terraforma 22 lipca 2026 roku. Serwer MCP w repozytorium render-oss/render-mcp-server ma Apache 2.0. Wtyczki do narzędzi AI, render-oss/skills i render-oss/render-plugin-claude-code, mają MIT z notą praw autorskich na rok 2026.

Najciekawiej wygląda repozytorium render-oss/sdk, w którym leżą klienty dla trzech języków. W katalogu głównym nie ma żadnego pliku licencyjnego. Podkatalogi python i go mają własny plik LICENSE z tekstem Apache 2.0. Podkatalog typescript nie ma pliku licencyjnego wcale, za to jego package.json deklaruje "license": "MIT". Skutek jest taki, że ten sam kod SDK rozchodzi się pod dwiema różnymi licencjami zależnie od języka.

Rozpakowanie opublikowanych paczek potwierdza rozjazd. Pakiet npm @renderinc/sdk w wersji 1.0.0, wydany 21 sierpnia 2026 roku, deklaruje w rejestrze MIT, zawiera 119 plików z realnym skompilowanym kodem i ani jednego pliku licencyjnego. Pakiet PyPI render w wersji 1.0.1, wydany tego samego dnia, nie ma w metadanych pola license, ma za to klasyfikator License :: OSI Approved :: Apache Software License i faktycznie niesie plik render-1.0.1.dist-info/licenses/LICENSE z pełnym tekstem Apache 2.0 oraz 792 pliki .py. Jeśli prowadzisz w firmie listę licencji zależności, wpisz MIT dla klienta TypeScript i Apache 2.0 dla klienta Pythona, bo to dwie różne pozycje.

Dwie pułapki nazewnicze. Pakiet npm render-cli to nie jest klient Rendera, tylko cudze narzędzie do renderowania szablonów Jade i Handlebars, ostatnio wydane w maju 2017 roku na licencji ISC. Klient Rendera instaluje się przez Homebrew albo pobiera z wydań na GitHubie. Pakiet PyPI render_sdk to z kolei zadeklarowana przez samego wydawcę atrapa zgodnościowa ze statusem Development Status :: 7 - Inactive, która tylko wymusza instalację pakietu render w tej samej wersji.

render.yaml, czyli Blueprint

Konfiguracja jako kod ma tu postać jednego pliku render.yaml w korzeniu repozytorium. Poniżej działający szkielet aplikacji webowej z bazą, wyłącznie z polami, które faktycznie istnieją w specyfikacji.

services:
  - type: web
    name: api
    runtime: node
    plan: standard
    region: frankfurt
    buildCommand: npm ci && npm run build
    startCommand: npm run start
    preDeployCommand: npm run migrate
    healthCheckPath: /healthz
    autoDeployTrigger: checksPass
    maxShutdownDelaySeconds: 60
    envVars:
      - key: NODE_ENV
        value: production
      - key: SESSION_SECRET
        generateValue: true
      - key: DATABASE_URL
        fromDatabase:
          name: api-db
          property: connectionString
      - key: STRIPE_API_KEY
        sync: false

databases:
  - name: api-db
    plan: basic-1gb
    region: frankfurt
    postgresMajorVersion: "18"
    databaseName: api
    user: api
    diskSizeGB: 15
    connectionPool: pgbouncer

Kilka pól, które łatwo przeoczyć. autoDeployTrigger przyjmuje commit, checksPass albo off i zastępuje przestarzałe autoDeploy. sync: false oznacza, że wartość podajesz ręcznie w panelu, a Blueprint jej nie nadpisze. generateValue: true każe platformie wygenerować losowy sekret o długości 256 bitów. maxShutdownDelaySeconds musi być liczbą całkowitą od 1 do 300, domyślnie 30, i to jest czas między sygnałem SIGTERM a SIGKILL.

Autoskalowanie i dysk konfiguruje się w tej samej sekcji usługi, ale nie da się użyć obu naraz.

services:
  - type: web
    name: api
    runtime: node
    plan: pro
    scaling:
      minInstances: 1
      maxInstances: 3
      targetMemoryPercent: 60
      targetCPUPercent: 70
  - type: worker
    name: importer
    runtime: python
    plan: starter
    disk:
      name: data
      mountPath: /var/data
      sizeGB: 10

Autoskalowanie wymaga planu Pro dla workspace i jest wyłączone w środowiskach podglądu, gdzie usługa chodzi zawsze w liczbie instancji równej minInstances. Rozmiar dysku możesz tylko zwiększać.

Praca z wiersza poleceń i z Terraforma

Klient CLI instaluje się z tapa Homebrew albo z wydań na GitHubie, nie z npm.

# instalacja i logowanie
brew tap render-oss/render
brew install render
render login
render workspace set

# walidacja pliku Blueprint, wymaga CLI w wersji 2.7.0 lub nowszej
render blueprint validate render.yaml

W potoku ciągłej integracji CLI działa w trybie nieinteraktywnym, więc każde polecenie wymaga jawnego identyfikatora usługi i formatu wyjścia.

# wdrożenie konkretnego commita i zablokowanie potoku do skutku
render deploys create "$RENDER_SERVICE_ID" --commit "$GITHUB_SHA" --wait -o json

# zapytanie do bazy bez otwierania sesji interaktywnej
render psql "$RENDER_DATABASE_ID" -c "select count(*) from users" -o json

# lista usług w aktywnym workspace
render services -o text

Dostawca dla Terraforma pokrywa te same zasoby, ale nazwy planów zapisuje z podkreśleniem zamiast myślnika, co jest częstym źródłem błędów przy przepisywaniu konfiguracji z render.yaml.

resource "render_postgres" "api" {
  name          = "api-db"
  plan          = "pro_4gb"
  region        = "frankfurt"
  version       = "17"
  database_name = "api"
  database_user = "api"

  high_availability_enabled = true

  parameter_overrides = {
    max_connections = "200"
    shared_buffers  = "256MB"
  }
}

Cennik: abonament za workspace plus compute

Rachunek składa się z trzech niezależnych części: abonamentu za plan workspace, opłat mierzonych za transfer i minuty budowania oraz stawki za compute każdej usługi z osobna. Plany workspace na stronie cennika to Hobby za 0 USD, Pro za 25 USD miesięcznie, Scale za 499 USD miesięcznie i Enterprise z ceną negocjowaną. Wszystkie są opisane jako cena „plus compute”, więc sam abonament nie daje ani jednej działającej instancji.

23 kwietnia 2026 roku Render przebudował te plany i zmiana jest na tyle duża, że wszystkie starsze wpisy w sieci podają nieaktualne liczby. Zniknęły opłaty za miejsce w zespole: dawny plan Professional kosztował 19 USD za członka zespołu miesięcznie, a dawny Organization 29 USD za członka, dziś Pro i Scale mają stałą cenę i nieograniczoną liczbę osób. W drugą stronę poszedł transfer wychodzący: Hobby miał 100 GB w cenie, ma 5 GB, a Professional miał 500 GB, podczas gdy Pro ma 25 GB. Nadwyżka kosztuje 0,15 USD za GB. Domeny własne były na Professional bez limitu, teraz jest ich 15, a każda kolejna to 0,25 USD miesięcznie. Ruch przychodzący i ruch w sieci prywatnej w obrębie regionu nie są liczone wcale.

Stawki za compute usług webowych, prywatnych i workerów wyglądają tak.

Rozliczenie idzie co sekundę, więc usługa włączona na dobę i wyłączona kosztuje ułamek stawki miesięcznej. Cron jobs mają stawki minutowe i te stawki są spójne z tabelą powyżej: Starter kosztuje 0,00016 USD za minutę, co przy 43 200 minutach pełnego miesiąca daje 6,91 USD, czyli praktycznie tyle samo co 7 USD abonamentu za instancję Starter.

Minuty budowania są osobną pozycją: 500 miesięcznie na Hobby, 1000 na Pro, 5000 na Scale, potem 5 USD za każdy tysiąc. Szybszy potok budowania kosztuje 25 USD za tysiąc minut i wymaga planu Pro. Dedykowany zestaw adresów IP to 100 USD miesięcznie, a AWS Private Link 30 USD miesięcznie za maksymalnie trzy połączenia plus 0,03 USD za GB ruchu wychodzącego przez to połączenie.

Jedna klauzula z sekcji pytań na stronie cennika bywa pomijana: abonament Pro za dany miesiąc jest umarzany, jeśli workspace nie miał w tym miesiącu żadnych usług, także zawieszonych, ani żadnej aktywności. Dla planu Scale abonament naliczany jest zawsze.

Plan darmowy: usypianie i baza kasowana po 30 dniach

Zgodnie z dokumentacją planu darmowego darmowe instancje są dostępne dla usług webowych, Postgresa i Key Value, niezależnie od planu workspace. Podniesienie planu workspace nie zdejmuje z nich żadnego ograniczenia, bo instance type ustawia się osobno dla każdej usługi.

Darmowa usługa webowa jest usypiana po 15 minutach bez ruchu przychodzącego, przy czym liczą się zarówno żądania HTTP, jak i wiadomości WebSocket na istniejących połączeniach. Budzenie po kolejnym żądaniu trwa według dokumentacji około jednej minuty i przez ten czas przeglądarka dostaje stronę ładowania. To jest najczęstsze zaskoczenie na tej platformie i dyskwalifikuje darmową instancję jako odbiornik webhooków albo cel monitoringu. Osobny limit to 750 godzin instancji na workspace na kalendarzowy miesiąc, przy czym uśpiona usługa ich nie zużywa. Jedna usługa chodząca bez przerwy przez 31 dni zużywa 744 godziny, więc mieści się w limicie, ale druga taka już nie.

Reszta ograniczeń: brak dysków, brak dostępu przez SSH, brak skalowania poza jedną instancję, brak cache na brzegu sieci, brak zadań jednorazowych, brak możliwości odbierania ruchu z sieci prywatnej oraz zablokowane porty wychodzące 25, 465 i 587, czyli cały klasyczny SMTP. Kiedy usługa jest uśpiona, żądania do /robots.txt dostają automatyczną odpowiedź zakazującą indeksowania i nie budzą procesu.

Darmowa baza Postgres wymaga osobnej ostrożności, bo jej cykl życia kończy się usunięciem danych. Jest jedna na workspace, ma sztywne 1 GB miejsca, nie obsługuje kopii zapasowych ani zarządzanej puli połączeń, a przede wszystkim wygasa 30 dni po utworzeniu. Po wygaśnięciu baza jest niedostępna, masz 14 dni okresu karencji na przeniesienie jej na płatny instance type, a po tym terminie Render kasuje bazę razem z danymi. Darmowa instancja Key Value ma 25 MB, trzyma dane wyłącznie w pamięci i traci je przy każdym restarcie. Jeśli potrzebujesz bazy, która przeżyje kwartał, płatna instancja jest jedynym wariantem, a ogólne zasady doboru rozmiaru opisuje PostgreSQL.

Render Postgres i realny rachunek za aplikację

Od czasu wprowadzenia planów elastycznych compute i storage bazy rozlicza się osobno. Instance type ustawia tylko procesor i pamięć, a miejsce na dysku kosztuje 0,30 USD za GB miesięcznie i można je wyłącznie zwiększać, do wielokrotności 5 GB. Domyślny rozmiar dysku zależy od poziomu: 1 GB dla Free, 15 GB dla Basic, 100 GB dla Pro i 250 GB dla Accelerated. To znaczy, że cena z tabeli nigdy nie jest pełną ceną bazy.

Z tej tabeli wychodzi pułapka doboru planu. Basic-4gb daje 2 CPU i 4 GB RAM za 75 USD, a Pro-4gb daje 1 CPU i 4 GB RAM za 55 USD i dopiero poziom Pro dopuszcza wysoką dostępność. Jeśli liczy się pamięć, a nie rdzenie, Basic-4gb jest po prostu droższy od sąsiada z wyższego poziomu. Okno odzyskiwania do punktu w czasie zależy od planu workspace i wynosi 3 dni na Hobby oraz 7 dni na Pro i wyżej.

Policzmy najmniejszą sensowną konfigurację produkcyjną, czyli usługa webowa plus baza. Na planie Pro: 25 USD za workspace, 25 USD za instancję Standard z 2 GB RAM i 19 USD za Basic-1gb wraz z 4,50 USD za domyślne 15 GB dysku. Razem 73,50 USD miesięcznie, w cenie 25 GB transferu wychodzącego i 1000 minut budowania. Wariant oszczędny na planie Hobby: 0 USD za workspace, 7 USD za instancję Starter i 10,50 USD za Basic-256mb z dyskiem, razem 17,50 USD miesięcznie, ale z jednym miejscem w zespole, 5 GB transferu i oknem odzyskiwania skróconym do 3 dni. Wariant z zapasem mocy: 25 USD za workspace Pro, 85 USD za instancję Pro, 55 USD za Pro-4gb i 30 USD za domyślne 100 GB dysku, razem 195 USD miesięcznie. Strona cennika nie wykazuje osobno kosztu instancji zapasowej dla wysokiej dostępności, więc tej pozycji w rachunku nie ma i nie zgaduję jej wysokości.

Do tego dochodzi transfer ponad limit. Aplikacja na planie Pro wysyłająca 100 GB miesięcznie zapłaci za 75 GB nadwyżki po 0,15 USD, czyli 11,25 USD.

Render na tle Railway, Fly.io, Vercel, Netlify i Coolify

Sedno różnicy leży w modelu rozliczenia, nie w liście funkcji.

Model stałej instancji wygrywa wtedy, gdy usługa pracuje przez większość doby. Wtedy rachunek jest znany z góry co do dolara i nie zależy od tego, czy ktoś zapętlił zadanie w tle. Model za zużycie wygrywa przy obciążeniu nierównomiernym, bo instancja stojąca bezczynnie przez 20 godzin na dobę i tak kosztuje na Renderze pełną stawkę. Punkt przecięcia leży mniej więcej tam, gdzie średnie wykorzystanie instancji spada poniżej jednej trzeciej, chociaż to zależy od profilu obciążenia i traktuj tę granicę jako zgrubne przybliżenie, a nie wyliczenie.

Wady wprost. Nie ma wariantu instalowanego na własnym serwerze, więc migracja poza Render to przepisanie całej warstwy uruchomieniowej, a render.yaml nie da się nigdzie indziej użyć. Koszt rośnie skokowo: między instancją Standard za 25 USD a Pro za 85 USD nie ma nic pośredniego, więc aplikacja, której zabrakło 200 MB pamięci, przeskakuje na potrójny rachunek. Plan darmowy nadaje się do prototypu i do nauki, ale nie do niczego, co ma odpowiadać w ciągu sekundy albo przeżyć miesiąc.

Typowe błędy

Traktowanie darmowej usługi webowej jak zwykłego endpointu. Po 15 minutach ciszy usługa śpi, a pierwsze żądanie czeka około minuty, więc integracja z bramką płatności albo z zewnętrznym monitoringiem zwróci timeout, zanim proces wstanie.

Zbudowanie czegokolwiek trwałego na darmowej bazie Postgres. Termin 30 dni od utworzenia jest sztywny, a po 14 dniach karencji dane znikają bez możliwości odzyskania.

Czytanie ceny bazy z jednej kolumny. Basic-1gb to 19 USD za compute i osobne 4,50 USD za domyślne 15 GB dysku, a Pro-4gb to 55 USD plus 30 USD za domyślne 100 GB.

Wybranie Basic-4gb zamiast Pro-4gb przy tej samej ilości pamięci. Różnica to 20 USD miesięcznie na niekorzyść niższego poziomu i brak wysokiej dostępności.

Opieranie budżetu na liczbach sprzed 23 kwietnia 2026 roku. Limit transferu na planie Hobby spadł ze 100 GB do 5 GB, a na dawnym Professional z 500 GB do 25 GB na Pro.

Instalowanie render-cli z npm. To pakiet innego autora z 2017 roku do renderowania szablonów, nie klient tej platformy.

Ustawienie pola branch w render.yaml przy włączonych środowiskach podglądu. Wszystkie podglądy będą wtedy budowane z tej jednej gałęzi, a nie z gałęzi pull requesta, więc zmian po prostu nie zobaczysz.

Podpięcie dysku do usługi, która ma się skalować. Usługa z dyskiem nie skaluje się poziomo, a rozmiaru dysku nie da się później zmniejszyć.

FAQ

Czy darmowa aplikacja na Renderze zasypia?

Tak. Darmowa usługa webowa jest usypiana po 15 minutach bez ruchu przychodzącego, a jej wybudzenie trwa według dokumentacji około minuty. Dodatkowo workspace ma 750 darmowych godzin instancji na miesiąc kalendarzowy, które nie przechodzą na kolejny miesiąc.

Co dzieje się z darmową bazą Postgres po 30 dniach?

Wygasa i staje się niedostępna. Masz wtedy 14 dni na przeniesienie jej na płatny instance type. Po tym okresie Render usuwa bazę razem z całą zawartością, a kopii zapasowych darmowa baza nie ma.

Ile realnie kosztuje aplikacja webowa z bazą?

Na planie Pro z instancją Standard i bazą Basic-1gb wychodzi 73,50 USD miesięcznie, licząc 25 USD za workspace, 25 USD za compute usługi, 19 USD za compute bazy i 4,50 USD za jej domyślny dysk. Wariant na Hobby ze Starterem i Basic-256mb to 17,50 USD miesięcznie.

Czy Render da się uruchomić na własnym serwerze?

Nie. Otwarte są tylko klient CLI, dostawca dla Terraforma, serwer MCP i SDK, wszystkie na licencjach permisywnych. Sama platforma jest zamknięta i nie ma wariantu instalowanego u siebie, więc wyjście z Rendera oznacza odtworzenie warstwy uruchomieniowej gdzie indziej.

Kiedy Railway wypada lepiej od Rendera?

Wtedy, gdy usługa przez większość doby nie robi nic. Render pobiera pełną stawkę za instancję niezależnie od obciążenia, więc rozliczenie za faktyczne zużycie jest tańsze dla środowisk testowych i zadań uruchamianych sporadycznie. Przy usłudze pracującej bez przerwy zaleta znika.

Czy Render liczy ruch przychodzący?

Nie. Rozliczany jest wyłącznie ruch wychodzący do internetu, w tym odpowiedzi HTTP i WebSocket oraz połączenia inicjowane przez usługi. Ruch w sieci prywatnej między usługami w tym samym regionie oraz strumienie logów i metryk do zewnętrznych systemów obserwowalności nie są liczone.