Ismerős a helyzet? Pénteken kiraktad az új alkalmazást Vercelre, hétfőre már megy is az ügyfélnek. Két hónappal később jön az első számla, és kiderül, hogy a sávszélességért már havi 89 dollárt fizetsz egy olyan rendszerért, amit hárman használnak. A Supabase mellé. A Resend mellé. És még nincs is benne a háttérben futó feladatkezelő, mert azt egy másik szolgáltatón futtatod, plusz 12 dollár.

Az ötletből éles termék lett, és a Vercel árazási modellje, ami az első hónapban barát volt, most már a legnagyobb költségtételed. Pedig a háttér-logikád 80 százaléka egyébként sem oda való.

Ebben a cikkben arról lesz szó, hogy mikor van értelme Vercelen maradni, és mikor érdemes saját szerverre költözni, kifejezetten egyedi alkalmazásokat fejlesztő csapatok és fejlesztők szemszögéből. Nem fogom azt mondani, hogy a Vercel rossz. Sok mindenre kiváló. Csak van egy pont, ahol egyszerűen már nem ez a megfelelő eszköz.

Röviden a lényeg:

• A Vercel kiváló statikus oldalakhoz, marketing site-hoz, kisebb Next.js alkalmazásokhoz.
• Ahogy nő a projekt (saját háttérlogika, adatbázis, ütemezett feladatok, fájlkezelés), a Vercel ára egyre meredekebben emelkedik.
• Egy 5-6 eurós havi díjú szerveren ugyanaz futhat Coolify-jal vagy Dockerrel, git push utáni automatikus telepítéssel, sokszor 10-20-szor olcsóbban.
• A platform-függetlenség nem ideológiai kérdés. Ha a háttérlogika, az adatbázis és az alkalmazás egy belső hálózaton beszél egymással, az sebességben és biztonságban is jobb.
• A telepítéstől és karbantartástól való félelem érthető, de 2026-ban már megoldott. Nem kell hozzá külön DevOps csapat.

Mire jó a Vercel valójában?

Mielőtt belemennék, hogy miért költöznek el sokan, tegyük le tisztán: a Vercel konkrét feladatokra a legjobb eszköz a piacon.

Ha a projekted ezek közül egy, akkor maradj rajta:

• Marketing oldal vagy landing oldal (statikus tartalommal)
• Dokumentációs oldal
• Tisztán előtér-oldali alkalmazás, ami külső szolgáltatások adatait jeleníti meg
• Kis vagy közepes Next.js alkalmazás, ahol a háttérlogika 3-4 egyszerű végpontból áll
• Korai fázisú projekt, amin még 10-20 felhasználó sincs, és gyorsan kell változtatni

Ezekre tényleg verhetetlen a fejlesztői élmény. Minden pull request-re automatikusan kapsz egy előnézeti környezetet, a tartalomkiszolgálás globális, a beállítás minimális. Ezek valódi előnyök.

A gond ott kezdődik, amikor az alkalmazásod átlépi azt a határt, ahol már nem egy "Next.js oldal pár háttérvégponttal", hanem egy rendes alkalmazás saját adatmodellel, háttérben futó feladatokkal, időzítésekkel, és néha egy Python szkripttel, ami PDF-eket állít elő.

És ezen a határon a legtöbb egyedi ügyfélprojekt átesik a második vagy harmadik hónapban.

Hol borul fel a Vercel modell egyedi alkalmazásnál?

1. A háttérlogika nem oda való

A Vercel alapfeltevése: minden kérés egy önálló kis program, ami pár száz milliszekundum alatt lefut és kilép. Ez a következőkre rossz:

• Hosszan futó folyamatok. PDF készítés, képfeldolgozás, külső rendszerekkel való szinkronizálás. A Vercel ingyenes csomagján a maximális futási idő 10 másodperc, a fizetősön 60 másodperc. Ha valami 2 percig fut nálad, azt nem itt fogod megoldani.
• Valós idejű kapcsolatok (WebSocket). Vercelen ezt nem tudod natívan futtatni. Külön szolgáltatást kell mellé venni (Pusher, Ably), ami plusz költség és plusz függőség.
• Háttérben futó és időzített feladatok. Nincs rá natív megoldás. Mehetsz Upstash QStash-re, Inngestre, Trigger.dev-re, de mindegyik külön szolgáltatás, külön számlával és külön felülettel.
• Memóriában tárolt állapot vagy gyorsítótár. A háttérlogika minden hívásnál újraindul. Ha kell gyorsítótár, Redis-t kell mellé venned, megint külön.

Egy egyedi ügyviteli rendszer, webshop-háttér vagy SaaS alkalmazás mindegyikből csinál egyet, sokszor mindet egyszerre. És minden új igény egy újabb külső szolgáltató, egy újabb számla, egy újabb felület amit figyelni kell.

2. Az adatbázis-kapcsolat ismert fájdalompont

Ahogy a Vercel működik, minden kérésnél új adatbázis-kapcsolat nyílik. Ha hirtelen 200 felhasználó kattint egyszerre, akkor 200 új kapcsolatigény keletkezik, és egy átlagos PostgreSQL adatbázis ettől eldől.

A megoldás egy közvetítő réteg (PgBouncer, Supabase saját pooler-e). Ez működik, de plusz réteget jelent és bizonyos adatbázis-funkciók nem mennek át rajta. Például a valós idejű értesítések (LISTEN/NOTIFY) vagy az előkészített lekérdezések egy része korlátozott.

Egy saját szerveren futó alkalmazás egy stabil kapcsolat-készletet tart fenn, az adatbázis ugyanazon a gépen vagy ugyanazon a belső hálózaton van, és a válaszidő mikromásodpercben mérhető, nem milliszekundumban.

3. A költségek nem lineárisan nőnek

Vegyünk egy konkrét helyzetet: napi 200 aktív felhasználós belső céges alkalmazás. Next.js előtér, Node.js háttérrel, PostgreSQL adatbázis, képfeldolgozó háttérfolyamat, fájlok S3-ba mentve.

Vercel és külső szolgáltatások havi költsége (nagyságrendileg):

Tétel	Költség
Vercel Pro (felhasználónként)	20-40 dollár
Vercel futási idő túllépés	20-60 dollár
Vercel sávszélesség	20-50 dollár
Supabase Pro (adatbázis)	25 dollár
Upstash (Redis és feladatkezelő)	10-30 dollár
Resend (email küldés)	20 dollár
Hibakövetés (Sentry)	26 dollár
Összesen	150-250 dollár havonta

Ugyanez egy Hetzner szerveren:

Tétel	Költség
Hetzner szerver (2 mag, 8 GB RAM)	~14 euró
Mentés-tároló	~4 euró
Domain és SSL (Let's Encrypt)	0 euró
Saját adatbázis, Redis, feladatkezelő, alkalmazás	a szerveren futnak
Összesen	~18 euró havonta (kb. 20 dollár)

Igen, a szerveren valakinek be kell állítania és karbantartania ezt, ezzel mindjárt foglalkozom. De a számokon először érdemes átaludni egyet: havi 150 dollár szemben a havi 20-szal, és ez még csak közepes forgalomnál van. Magasabb használatnál az olló tovább nyílik.

4. Függés a szolgáltatótól

Ez puhább érv, de hosszú távon ez a legdrágább. Ami Vercel-specifikus:

• A Next.js beállításaiban Vercel saját képoptimalizálása
• Saját futtatókörnyezetek (Edge és Node) közötti viselkedési különbségek
• Olyan közbenső viselkedések, amik más szerveren máshogy mennek
• A @vercel/postgres, @vercel/blob, @vercel/kv csomagok mind Vercel-specifikusak

Amíg Vercelen vagy, ezek kényelmesek. Amikor költöznél, ezeket mind ki kell cserélned. Egy év fejlesztés után az alkalmazásod már nem egy "Next.js alkalmazás", hanem egy "Vercelen-futó-Next.js-alkalmazás", és ez két különböző dolog.

Saját szerveren a felhasznált eszközök (Node.js, PostgreSQL, Redis, Nginx, Docker) több mint 10 éve léteznek és bárhova vihetők. Másik szerver, másik szolgáltató, saját géptermi gép, AWS, mindegy.

"De én csak git push-t akarok, és fusson"

Ez a leggyakoribb és legjogosabb fenntartás. Pontosan ezt a kényelmet szoktad meg a Vercelen, és érthető módon nem akarsz visszamenni abba a világba, ahol SSH-zol, fájlokat másolsz, és imádkozol hogy a telepítés közben ne dőljön el a szerver.

A jó hír: 2026-ban már nem kell. A modern saját szerverre telepíthető eszközök (Coolify, Dokploy, CapRover) pontosan ezt az élményt adják vissza saját szerveren is:

• Összekötöd a GitHub tárolódat
• Beállítod, hogy melyik ág melyik környezetbe települjön
• git push origin main, automatikus építés, leállás nélküli csere, kész
• Előnézeti környezet minden pull request-re
• Automatikus SSL Let's Encrypttel
• Konténerekbe csomagolt, elszigetelt környezet

Egy példa: egy Coolify-jal felhúzott Hetzner szerveren a Next.js alkalmazás, a PostgreSQL, a Redis és a feladatkezelő mind együtt fut, ugyanazon a belső Docker-hálózaton. Az adatbázishoz tartozó kapcsolat egyszerű belső név (postgres://app:jelszo@db:5432/app), nem publikus interneten keresztül. A válaszidő ezredmásodperc alatti, az adatbázis-kapcsolatért fizetett külön díj pedig nincs.

A git push utáni automatikus telepítés beállítása egyszeri körülbelül fél órás munka. Utána ugyanaz a folyamat, mint Vercelen.

A platform-függetlenség gyakorlati előnyei

Szokták ezt "ideológiai" érvként elintézni, de van pár nagyon konkrét, mérhető hatása.

Belső hálózatos kommunikáció

Vercel-felépítésben a Next.js alkalmazás a Vercel oldalán fut, az adatbázis a Supabase-en, a háttérben futó feladatok az Upstash-en, a Redis a Vercel saját szolgáltatásán. Minden kérés ezek között a publikus interneten megy, igaz, titkosítva, de a hálózati ugrások latenciája összeadódik.

Saját szerveren mindezek egy belső hálózaton futnak. A háttérben futó feladat és az adatbázis ugyanazon a belső címen beszél. Egy adatbázis-lekérdezés 1-2 milliszekundum helyett tizedmilliszekundum alatt fut le. Egy lassú végponton ez akár 50 milliszekundum és 500 milliszekundum közötti különbség.

Az adatbázis minden funkciója elérhető

Saját PostgreSQL-en megy a valós idejű értesítés (LISTEN/NOTIFY), az adatbázis-szintű időzítés (pg_cron), külső adatforrásokhoz való kapcsolódás, saját bővítmények (térinformatikai funkciók, mesterséges intelligencia projektekhez vektoros keresés). A közvetítő rétegek mögött ezek egy része nem megy, vagy csak korlátozottan.

Kiszámítható költség

A Vercel futási idő és sávszélesség használat-alapú, amennyit használsz, annyit fizetsz. Egy elszabadult keresőrobot vagy egy váratlan forgalmi csúcs egy ügyfél marketing kampánya után simán megdob egy 400 dolláros számlát. Saját szerveren a havi díj fix. Ha túlterhelődik, lassú lesz, de a kártyádról nem megy le tízszer annyi pénz hónap végén.

Adattárolási megfelelőség

EU-s ügyfélnek dolgozol? GDPR-érintett adatot kezelsz? Egy Hetzner falkenstein-i szerveren az adat garantáltan EU-ban van, és tudod is hol. Vercel és Supabase és Upstash és Resend felállásban négy különböző helyen lehet az adat, és minden szolgáltatónál külön adatfeldolgozói szerződést kell végignézned. A NIS2-re való felkészülésnél ez nem mellékes szempont 2026-ban.

Az ügyfeleimnél sokan pont ezen a ponton akadnak el. Értik, hogy a saját szerver olcsóbb és technikailag is jobb, de a "ki frissíti a biztonsági javításokat, ki figyel ha hajnali 3-kor leáll" felelősség visszariasztja őket. Ha ismerős az érzés, a Winzolnál pont ezt csináljuk. Havidíjas csomagban átvesszük a szerver karbantartását, figyelését és mentését, hogy Te a kódot írhasd. Konkrétan ezért van a cég.

Mikor maradj Vercelen, és mikor költözz?

Hogy ne legyek egyoldalú, itt egy egyenes döntési táblázat:

Helyzet	Ajánlott választás
Marketing oldal, dokumentáció, blog	Vercel
Tiszta előtér-alkalmazás, külső szolgáltatásokat hív	Vercel
Korai szakaszú projekt, 0-50 felhasználó	Vercel (de tervezd a későbbi költözést)
Next.js plusz saját Node.js/Express háttérlogika	Saját szerver
Bármi, ami háttérben futó feladatot vagy időzítést igényel	Saját szerver
Saját PostgreSQL haladó funkciókkal	Saját szerver
Valós idejű funkciók (WebSocket)	Saját szerver
Havi 100 dolláros Vercel számla már most	Saját szerver (kb. 2 hónap alatt megtérül)
EU-s GDPR érintett adat, NIS2 hatály	Saját szerver EU-ban
Egyedi ügyviteli rendszer, B2B SaaS	Saját szerver

A havi 100 dolláros Vercel számla a legtisztább jelzés. Ha már most ennyit fizetsz, és az alkalmazásod nőni fog, akkor a következő 12 hónapban legalább 1500 dollárt spórolsz egy költözéssel. Mindezt úgy, hogy technikailag is jobb helyre kerülsz.

Gyakori hibák, amiket érdemes elkerülni a költözésnél

1. Ne költöztess át mindent egyszerre. Először a háttérben futó feladatokat és az időzítéseket. Ezek a legdrágábbak a Vercel körüli szolgáltatásokon, és a legkönnyebben átvihetők.
2. Ne menj havi 4 dolláros szerverre. Egy komoly alkalmazás minimum 4-8 GB RAM-ot szeret. A spórolás itt nem éri meg. A túl olcsó szolgáltatóknál a teljesítmény kiszámíthatatlan.
3. Ne használj root felhasználót. Külön felhasználó, csak kulccsal való belépés, fail2ban, tűzfal. Ezek alap higiénia, nem opcionálisak.
4. A mentés ne csak pillanatkép legyen. A szolgáltatónál csinált pillanatkép jó, de máshova mentés is kell (másik szolgáltató tárhelyére vagy S3-ba). Ha a fiókod kompromittálódik, a pillanatkép ugyanott van.
5. A figyelés a telepítéssel együtt kerüljön be, ne később. Uptime Kuma vagy Better Stack 15 perc alatt felmegy, és reggel 8-kor nem az ügyfél jelzi, hogy áll a rendszer.

Összefoglalás

A Vercel kiváló platform statikus oldalakhoz és kisebb projektekhez. Ahol elromlik a számolás, az az egyedi alkalmazás-fejlesztés. Amint van saját háttérlogika, saját adatbázis, háttérben futó feladatok, időzítések, vagy bármi ami nem fut le 200 milliszekundum alatt, a Vercel árazása és felépítése ellened dolgozik.

Egy modern saját szerverre telepíthető eszközzel (Coolify, Dokploy) a git push utáni telepítés kényelmét saját szerveren is megkapod. Közben 10-20-szor olcsóbban futtatsz, az adataid egy helyen vannak, belső hálózaton kommunikálnak, és nem függsz négy különböző szolgáltató árazási döntéseitől.

A költözés egyszeri munka, nem ideológia. A számok döntenek.

---

Ha most ott tartasz, hogy a Vercel számla már fáj, de a "ki üzemelteti?" kérdés még megválaszolatlan, nézd meg a Winzol VPS üzemeltetési csomagjait. Konkrétan azt csináljuk, amit ebben a cikkben technikailag indokoltunk: felhúzzuk a szerveredet Coolify-jal vagy közvetlen Dockerrel, beállítjuk a git push utáni telepítést, karbantartjuk a biztonsági frissítéseket, figyeljük a rendszert és mentjük az adatokat. Mindezt havidíjas csomagban, fix áron.

Vagy ha előbb látni szeretnéd a számokat a saját projektedre vetítve: ingyenes 20 perces átvilágítás, ahol átnézzük a jelenlegi Vercel, Supabase és Upstash felállásodat, és megmondjuk őszintén, hogy érdemes-e egyáltalán költöznöd, vagy maradj ahol vagy.