Hogyan tedd nyilvánossá a localhost-alkalmazásaidat VPS nélkül

Az alkalmazásod fut. Elindítottad a dev szervert, megnyitottad a http://localhost:3000címet, és azt csinálja, amit kell. Aztán valaki linket kér, és rájössz, hogy a képernyődön látható URL rajtad kívül senkinek nem jelent semmit.

Három módon adhatsz nyilvános URL-t egy localhost-alkalmazásnak VPS nélkül, plusz van egy gyorsabb lehetőség, ha a másik személy a helyi hálózatodon van, és a választás közöttük nem eszközkérdés. Az a kérdés, meddig kell elérhetőnek maradnia a dolognak, és futhat-e máshol, mint a laptopodon. Alább minden út, az URL-t adó parancs, és pontosan az, ami miatt az az URL nem fog többé működni.

Röviden

• Valakinek a Wi-Fi-den látnia kell: kösd a dev szervert az összes hálózati interfészre, és add meg a LAN IP-det. Másodpercek alatt kész, és halott, amint a látogatód elhagyja a hálózatodat.
• Olyan link kell, amit bárki megnyithat a következő egy órában: futtass egy alagutat (cloudflared, ngrok, localtunnel, localhost.run). Nyilvános HTTPS URL nagyjából egy perc alatt, routerbeállítás nélkül, és az elindító folyamattal együtt hal meg.
• Akkor is mennie kell, amikor a laptopod le van csukva: told fel az alkalmazást egy ingyenes hosztingcsomagra. Ez leválasztja az alkalmazást a laptopodról, és új szabályokat hoz a bankkártyákról, a kereskedelmi használatról és arról, hogy az adataid túlélik-e az újraindítást.
• Az alkalmazásodnak nincs szüksége szerverkódra a kérés pillanatában: buildeld le, és tedd a statikus kimenetet egy statikus hosztra. Online maradhat a laptopod nélkül, és nincs felébresztendő alkalmazásfolyamat, amíg a hoszt fiókja és használati keretei még megfelelnek.
• Egy alapértelmezés, amit érdemes ismerni: next dev és python -m http.server már minden hálózati interfészen figyel, mindenféle kapcsoló nélkül. Ha azt hitted, a dev szervered csak a laptopodon látható, tévedtél.

Melyik út illik az alkalmazásodhoz

E négy út közül három nyilvános internetes URL-t ad az alkalmazásodnak; az első csak a saját hálózatodat éri el, ettől egyszerre a leggyorsabb és a legkorlátozottabb. Rendezd őket aszerint, meddig kell túlélnie az URL-nek, és a választás nagyjából magától adódik.

Hogy mely sorok nyitottak előtted, három dolgon múlik, amit a saját projektedben ellenőrizhetsz:

• Szüksége van az alkalmazásnak a szerverkódodra a kérés pillanatában? Egy Flask- vagy FastAPI-útvonal, egy server.js végpont vagy kérésspecifikus szerverlogika szerveroldali hosztot igényel. A build-időben futó szerverkód nem zárja ki automatikusan a statikus telepítést: a Next.js Server Components futhatnak a next buildalatt, a statikus GET Route Handlerek pedig előrenderelhetők. Ha minden futásidejű kérés statikus fájlként kiszolgálható vagy közvetlenül a böngészőből egy külső API-hoz küldhető, a statikus út továbbra is nyitva áll.
• Olvas vagy ír olyan fájlt, amit meg kell őriznie? Egy adatbázisfájl (.db, .sqlite), egy feltöltési mappa, egy JSON-fájl, amit szerkeszt. Ha igen, telepítés előtt nézd meg a hoszt tárolási modelljét. A Render ingyenes webszolgáltatásai és a Koyeb ingyenes példányai múlékony helyi tárolót használnak, a Vercel Functions pedig csak olvasható fájlrendszerrel és ideiglenes /tmp területtel dolgozik. A tartós állapotot tedd tartós kötetbe, adatbázisba vagy objektumtárolóba, ahelyett, hogy feltételeznéd, az alkalmazás helyi lemeze túléli.
• Szüksége van titokra futásidőben? Egy .env fájlban tárolt kulcs változatlanul működik az első két úton, mivel az alkalmazás továbbra is a gépeden fut. A másik kettőn újra megadod a szolgáltató környezeti beállításaiban, és nem lehet benne a repóban, amit pusholsz.

Oszd meg a saját hálózatodon

next dev már a géped összes hálózati interfészén figyel (csak ennyit jelent a 0.0.0.0 , amikor látod), és ugyanezt teszi a python -m http.serveris. Egyiknek sem kell kapcsoló, így a most futó dev szervered valószínűleg már most elérhető a telefonodról ugyanazon a Wi-Fi-n.

A Next.js a -H kapcsolót dokumentálja a hosztnév megváltoztatására, alapértelmezett értéke 0.0.0.0, a Python dokumentációja pedig azt írja, hogy a modul minden interfészre rákapcsolódik , hacsak nem adod meg a --bind 127.0.0.1kapcsolót. Ettől ez a leggyorsabb módja egy localhost-alkalmazás megosztásának: nincs fiók, nincs telepítés, nincs deploy. A többi gyakori dev szervernek szólni kell.

# Already listening on all interfaces. Nothing to add.
next dev
python -m http.server 8000
streamlit run app.py

# Needs the flag.
npm run dev -- --host             # Vite
flask run --host=0.0.0.0
uvicorn main:app --host 0.0.0.0   # FastAPI

A Vite dokumentációja: server.host alapértéke localhost, és elfogadja a --host kapcsolót a parancssorban vagy a server.host: '0.0.0.0' beállítást a konfigurációs fájlban. Az Uvicorn alapértelmezése 127.0.0.1, ami a FastAPI-t is lefedi, hiszen az futtatja. A Streamlit a server.address értéket üresen hagyja, és a konfigurációs referenciája megjegyzi, hogy a beállítása arra az egy címre korlátozza a hozzáférést : üresen hagyva nincs korlátozás.

Ezután kell a cím, amit továbbadsz. Ez a géped saját IP-je a helyi hálózaton, nem a localhost:

# macOS
ipconfig getifaddr en0

# Linux
hostname -I

# Windows (PowerShell)
ipconfig | findstr IPv4

Add meg a látogatódnak a http://<that-address>:3000 címet, és bent van. A bökkenő az egész út alakja: ez a cím a hálózatodon kívül nem jelent semmit. Amint másik Wi-Fi-n, mobilneten vagy otthon van, a link számára halott.

Megjegyzés: ha a parancs rendben lefut, és a másik eszköz mégsem tud csatlakozni, szinte mindig az operációs rendszer tűzfala a hibás, nem a parancs. Az Apple tűzfal-dokumentációja szerint a macOS figyelmeztetést jelenít meg egy még nem engedélyezett alkalmazásnál, és megtagadja a kapcsolatot, amíg nem cselekszel. A Windows ehelyett megkérdezi, melyik hálózati profil érvényes, és külön szabályokat tart a privát és a nyilvános hálózatokhoz. Otthoni vagy irodai hálózaton válaszd a Privátot. Soha ne a Nyilvánost.

Tedd egy alagút mögé

Az alagút egy kis program, amely az alkalmazásod mellett fut, és nyilvános HTTPS-címet ad neki. Egyetlen parancs nagyjából egy perc alatt ingyenes alagutat ad a localhosthoz, és érdemes előre tudni, hogy az URL abban a pillanatban meghal, amikor a parancs leáll:

cloudflared tunnel --url http://localhost:3000

A routereden semmi sem változik, a kapcsolat iránya miatt. A géped kimenő kapcsolatot nyit a szolgáltató peremhálózata felé, ugyanolyat, amilyet a böngésződ bármelyik oldal betöltéséhez, a szolgáltató pedig nyitva tartja, és ezen keresztül tolja vissza a bejövő kéréseket. A bejövő portok a te oldaladon zárva maradnak, ezért működik ez hotel-Wi-Fi-n, telefonos hotspoton és olyan otthoni kapcsolaton, amelynek routerét nem te kezeled.

Megjegyzés: ez az utolsó eset megér egy hatvanmásodperces ellenőrzést, mielőtt inkább a portátirányítást fontolgatnád. Nyisd meg a router állapotoldalát, keresd meg az általa jelentett WAN IP-t, és vesd össze a tényleges nyilvános IP-ddel bármelyik „mi az IP-címem” lekérdezésből. Ha a WAN IP a 100.64.0.0/10tartományba esik, valószínűleg CGNAT az oka. Ha a WAN IP és a nyilvános IP egyszerűen eltér, tudod, hogy van még egy NAT-réteg feljebb, de az lehet CGNAT vagy közönséges dupla NAT is. Mindkét esetben lehet, hogy a portátirányítás önmagában ezen a routeren nem elég. Ezt a tartományt az RFC 6598 megosztott címtérként tartja fenn, és ez az, ami mögé a szolgáltatód tesz, amikor kifogy a címekből.

A lehetőségek leginkább abban különböznek, mit kérnek tőled először.

A Cloudflare quick tunnel a fenti parancs: nincs fiók, nincs domain, egy véletlenszerű trycloudflare.com aldomain. A Cloudflare 200 folyamatban lévő kérésre korlátozza, e fölött 429-et ad vissza, nem támogatja a Server-Sent Eventset, és ugyanabban a dokumentációban kimondja, hogy az ingyenes alagutak tesztelésre és fejlesztésre valók, nem éles weboldal üzemeltetésére.

ngrok esetében először regisztrálni kell, aztán jöhet a ngrok http 3000. A jelenlegi ingyenes csomag 5 $ egyszeri, havonta meg nem újuló beépített keretet ad, legfeljebb 3 online végpontot, 1 GB forgalmat, 20 000 HTTP/S-kérést és egy közbeiktatott figyelmeztető oldalt, amin a látogatódnak át kell kattintania. Kapsz egy ingyenes, automatikusan kiosztott fejlesztői domaint is, amelyet az ngrok 2023-ban jelentett be , hogy véget vessen a régi panasznak, miszerint az URL minden újraindításkor változik.

localtunnel esetében nincs regisztráció és az npx-en kívül nincs telepítés: npx localtunnel --port 3000. Véletlenszerű aldomaint kapsz, és a README egyértelműen kimondja, hogy a --subdomain nevet kér, de nem garantálja.

localhost.run semmit nem telepít, mert az operációs rendszered beépített SSH-kliensét használja: ssh -R 80:localhost:3000 localhost.run. A dokumentációja megjegyzi, hogy nincs szükség letöltésre , és az ingyenes domainekhez fiók létrehozása sem kell.

VS Code a Ports panelen kínálja ezt, ami kényelmes, ha amúgy is a szerkesztőben élsz. GitHub- vagy Microsoft-bejelentkezést kér, és az alapértelmezés átver: a továbbított port privát, vagyis a látogatódat a te fiókoddal való bejelentkezésre kérik, amíg át nem állítod a portot nyilvánosra. (Csapattársnak jó. Az ügyfélnek, aki csak egy linkre kattintana, használhatatlan.)

Tailscale Funnel szintén tudja ezt, két olyan megkötéssel, ami általában eldönti a kérdést: az URL csak a saját tailneted domainjén élhet, és csak a 443-as, 8443-as és 10000-es porton figyelhet.

Bármelyiket választod, legyél tisztában azzal, mit adtál ki a kezedből. Hozzáférés-vezérlés nélküli nyilvános alagútnál minden, amit a dev szerver kiszolgál, elérhető bárkinek, akinél ott az URL, beleértve a soha nem linkelt útvonalakat és a bekapcsolva hagyott debug-felületeket is. Egy tizenöt perces demóhoz rendben van. Egy nyilvános Discordba bemásolt URL-hez már jóval kevésbé.

A lejárat azért ver át, mert úgy nézhet ki, mintha az alkalmazás romlott volna el. Az itteni gyors utak többsége továbbra is a laptopodon futó alagútszoftvertől függ: állítsd le a cloudflared, az ngrok, a localtunnel vagy a localhost.run SSH-munkamenetét, és a továbbítás leáll. A Tailscale Funnel kivétel, ha a --bgkapcsolóval futtatod, ami a Funnel-konfigurációt a háttérben futva tartja, és újraindítás után visszaállítja. Egyik sem tudja kiszolgálni a helyi alkalmazásodat, amíg maga a laptop offline. Egy alagutat napokig futva hagyhatsz, és pontosan addig működik, amíg le nem csukod a fedelet vagy el nem éred a kéréskorlátot.

Az alagút demóhoz a megfelelő eszköz, hosztinghoz a rossz: a rendelkezésre állása a laptopodé.

Engedd, hogy az alkalmazás elhagyja a gépedet

Ez az első út, ahol a laptopod már nem tartóelem, és az első, ahol a feltételek többet számítanak az eszközöknél. Itt nem egy óra vet véget a dolognak. Hanem a tétlenségi leállítás, a fájlrendszer visszaállítása vagy egy csomag, amely úgy dönt, hogy az alkalmazásod nem az, amit ingyenes példányon látni akar.

Az alábbi lehetőségek a folyamatos ingyenes csomagoktól a rövid próbaidőszakokig terjednek. Némelyik a keretein belül határozatlan ideig online tarthat egy alkalmazást; mások rögzített próbaidő után leállnak, vagy a számítási kapacitáshoz fizetős fiókot kérnek. Telepítés előtt nézd meg a számlázási, alvási és tárolási szabályokat.

Az alábbi ingyenes csomagok feltételeit 2026. szeptember 7-én ellenőriztük az egyes szolgáltatók saját ár- vagy dokumentációs oldalán.

A „Nincs megadva” azt jelenti, hogy a szolgáltató saját oldalai nem válaszolnak erre az ingyenes csomag esetében. Kezeld ismeretlenként, ne igenként vagy nemként.

Ezek közül három sor külön figyelmet érdemel, mielőtt belevágsz. A Fly.io-nak nincs folyamatos ingyenes csomagja: a próba 2 gépóra vagy 7 nap után lejár. A Koyebnél van ingyenes példány, de a regisztrációs és számlázási folyamata figyelmet igényel telepítés előtt. A Hugging Face ingyenesen tartja a Static Spaces-t, míg az új Gradio- és Docker-Space-ek fizetős fiókot igényelnek, a korlátozott ZeroGPU-kivételtől eltekintve. A Railway már nem tartozik ebbe a figyelmeztető listába: a 30 napos, 5 $ kredites próba után most 0 $-os Free csomagra vált, havi 1 $ erőforrás-kredittel.

Aztán ott az adatok kérdése, ahol egy működő alkalmazás csendben elromlik. A Render ingyenes webszolgáltatásai múlékony fájlrendszeren futnak, és a dokumentáció kereken kimondja: minden, amit oda írnak, a feltöltött képeket és a helyi SQLite-adatbázisokat kifejezetten beleértve, elvész minden újratelepítéskor, újraindításkor és tétlenségi leállításkor. A Vercel függvényei csak olvasható fájlrendszeren futnak, csupán ideiglenes munkaterülettel, így az alkalmazásod által írt SQLite-fájl ott sincs biztonságban. Ha az alkalmazásod fájlban tartja az állapotát, tedd át tartós tárolóba: hosztolt adatbázisba, objektumtárolóba vagy tartós kötetbe, ahol a platform kínál ilyet.

A tétlenségi leállítást érdemes megtapasztalni, mielőtt elköteleződsz. A Render ingyenes csomagján 15 perc tétlenség altatja el a szolgáltatást, és a következő kérés nagyjából egy perc alatt ébreszti fel, betöltőoldalt mutatva annak, aki a linkedre kattintott. Egy portfóliódarabnál vállrándítás. Egy ügyfélnél, aki hívás közben nyitja meg a linket, hatvan kellemetlen másodperc.

A PythonAnywhere-nél a csapda finomabb. Nincs tétlenségi leállítás, de az ingyenes webalkalmazás egy hónap után lejár, és leáll, hacsak rá nem kattintasz a PythonAnywhere által e-mailben küldött megújítási linkre, az ingyenes fiókok pedig korlátozott kimenő internet-hozzáférést kapnak, és csak a külső hosztok engedélyezési listáját érik el. Egy alkalmazás, amely e listán kívüli API-t hív, tökéletesen online marad, és minden, a nem engedélyezett API felé menő kérése elhasal (rémes debugolni, mert sehol semmi nem tűnik leállva).

Add ki statikus oldalként

Ha semmi, amit az alkalmazásod csinál, nem igényel szerverkódot a kérés pillanatában, a statikus hoszt itt a „beállítod és elfelejted” lehetőséghez a legközelebbi: online maradhat a laptopod nélkül, és nincs felébredésre váró alkalmazásfolyamat. A hoszt fiókja és használati keretei továbbra is érvényesek. Több alkalmazás felel meg, mint gondolnád, ezért érdemes a három kérdés közül az elsőt megválaszolni, mielőtt feltételezed, hogy szerveroldali hoszt kell.

A szabály szűkebb annál, hogy „van-e backendje”. Az alkalmazásod megfelel, ha minden kérése vagy a saját statikus fájljaidhoz megy, vagy közvetlenül a böngészőből valaki más API-jához. A Supabase vagy egy nyilvános API böngészőből való lekérése rendben van, azzal az egy kikötéssel, hogy a böngészőkódban ülő kulcs olyan kulcs, amit már közzétettél. Az ajtót az zárja be, ha a saját kódodnak minden kérésnél szerveren kell futnia.

Ha megfelel, a menet rövid:

npm run build   # Vite writes to dist/, a Next.js static export writes to out/

Ezután telepítsd a build kimenetét egy statikus hosztra. A Cloudflare Pages, a Netlify és a Vercel csatlakoztatott repóból is tud buildelni. A GitHub Pages egy branchből publikálhat statikus fájlokat, vagy GitHub Actions-szel futtathatja a keretrendszered buildjét és telepítheti a generált kimenetet.

A GitHub Pages korlátai elég élesek ahhoz, hogy már az elején számítsanak. Csak statikus, fiókonként egy felhasználói vagy szervezeti oldal, és olyan használati feltételek, amelyek kimondják, hogy nem ingyenes hoszting vállalkozásnak, e-kereskedelmi oldalnak vagy kereskedelmi SaaS-nak. Ha az alkalmazásod fizetéseket fogad majd, ez már az indulás előtt kizárja.

Ennek az útnak nincs alkalmazásfolyamat-lejárata. Addig működik, amíg a hosztingfiók aktív és a keretein belül marad, és attól kezdve nem illik, hogy az alkalmazásnak a kérés pillanatában szerveroldali munkára van szüksége.

Hol érnek véget az ingyenes utak

Az ingyenes utak különböző helyeken buknak el, nem egyszerre. Egy statikus hoszt már megoldja a laptop rendelkezésre állását, és stabil szolgáltatói URL-t ad. Egy ingyenes alkalmazáshoszt is képes erre, és néhány már tartós tárolót is ad. A VPS akkor kezd értelmet nyerni, amikor a követelmények halmozódnak: a saját szerveroldali folyamatodnak online kell maradnia, kiszámítható tartós tárolóra van szükséged, és az ingyenes csomag erőforrás- vagy használati szabályai már nem elegek.

Ezt a küszöböt érdemes tiszteletben tartani. Egy demó nem ok szervert venni, és egy kis forgalmú statikus projekt sem. Maradj alagútnál a rövid megosztáshoz, statikus hosztnál, amíg az alkalmazás tényleg statikus, és ingyenes alkalmazáshosztnál, amíg a keretei megfelelnek annak, amit futtatsz.

Válts VPS-re, ha mindig futó, saját kezelésű szerverre van szükséged, és hajlandó vagy vállalni a vele járó üzemeltetési munkát. A mi Linux VPS-ünk az egyik lehetőség, és egy másik szolgáltató hasonló VPS-e ugyanezt a munkát elvégzi. Az alkalmazáshoz méretezd a szervert, ahelyett, hogy feltételeznéd, a legkisebb csomag elég lesz.

Két dolog változik, ha megteszed. A platformhoszt által adott, git pushra épülő telepítési folyamat többé nem automatikus. Újraépítheted egy saját hosztolású PaaS-szal, például a Coolify vagy a Dokkusegítségével, vagy építhetsz saját CI/CD-utat, és mindkét esetben a frissítések és a karbantartás mostantól a tiéd.

A másik változás, hogy a gépen több lakik, mint az alkalmazás. Szívesen futtatja a Code Servert és a Claude Code-ot , ha inkább a szerkesztődet is ott tartanád, ami rajtad múlik: vagy kellemes ráadás, vagy egy teljesen új hétvége.

OLVASD

A legjobb önállóan hosztolt Heroku- és Vercel-alternatívák: Coolify, Dokku és társai

Gyakran ismételt kérdések

Miért nem működik a nyilvános URL-em, miután lecsuktam a laptopot?

Mert az alagút az őt létrehozó folyamathoz volt kötve, nem az alkalmazásodhoz. A laptop lecsukása vagy a terminál leállítása befejezi azt a folyamatot, a nyilvános URL meghal, az alkalmazásod pedig rendben van. Az alagút újraindítása új URL-t ad, hacsak az eszköz nem oszt ki neked fenntartott domaint. Ha a linknek túl kell élnie a laptopod alvását, az alkalmazásnak el kell hagynia a gépedet.

Kell domainnév ahhoz, hogy egy helyi alkalmazást nyilvános URL-re tegyek?

Nem, szinte minden esetben. A Cloudflare quick tunnel, az ngrok kiosztott fejlesztői domainje, a localtunnel, a localhost.run és a fenti ingyenes hosztingcsomagok mind ingyen adnak aldomaint a saját domainjükön. A kivétel a Cloudflare named tunnel, amelyhez a Cloudflare DNS-hez már hozzáadott domain kell.

Megnyithatja valaki másik Wi-Fi-hálózatról a helyi IP-címemet?

Nem. Egy olyan cím, mint a 192.168.1.42 , arra az eszközre mutat, amelyiké éppen az a cím azon a hálózaton, amelyhez most csatlakozol, ami bármely más hálózaton egy másik eszköz vagy a semmi. Aki a Wi-Fi-den kívül van, annak alagút, ingyenes hosztingcsomag vagy statikus hoszt kell helyette.

Ezek közül melyik működik, ha az alkalmazásomban bejelentkezés és adatbázis van?

Az azonos hálózatos és az alagutas út változatlanul működik, mert az alkalmazás továbbra is a gépeden fut. A statikus telepítés is működhet, ha a bejelentkezési és adatbázis-kérések közvetlenül a böngészőből egy hosztolt szolgáltatáshoz mennek, és egyetlen kéréshez sem kell privát szerveroldali kódnak futnia. Ha a saját hitelesítési vagy adatbázis-kódodnak a kérés pillanatában szerver kell, használj inkább szerveroldali hosztot. Ingyenes alkalmazáshoszton a tartós adatokat tartós tárolóban tartsd, ahelyett, hogy feltételeznéd, az alkalmazás helyi fájlrendszere túléli.