Jak opublikować aplikację z localhosta bez VPS

Twoja aplikacja działa. Uruchomiłeś serwer deweloperski, otworzyłeś http://localhost:3000, i robi to, co powinna. Potem ktoś prosi o link, a Ty odkrywasz, że adres URL na Twoim ekranie nie znaczy nic dla nikogo poza Tobą.

Są trzy sposoby, żeby dać aplikacji z localhosta publiczny adres URL bez VPS, plus jedna szybsza opcja, gdy druga osoba jest w Twojej sieci lokalnej, a wybór między nimi nie jest kwestią narzędzia. To kwestia tego, jak długo aplikacja ma pozostać dostępna i czy może działać gdzieś poza Twoim laptopem. Poniżej każda ścieżka, polecenie, które daje adres URL, i dokładnie to, co sprawi, że ten adres przestanie działać.

TL;DR

• Ktoś w Twojej sieci Wi-Fi musi to zobaczyć: podepnij serwer deweloperski do wszystkich interfejsów sieciowych i podaj swój adres IP w sieci LAN. Gotowe w kilka sekund, martwe w chwili, gdy gość opuści Twoją sieć.
• Potrzebujesz linku, który każdy otworzy w ciągu najbliższej godziny: uruchom tunel (cloudflared, ngrok, localtunnel, localhost.run). Publiczny adres HTTPS w około minutę, bez zmian w routerze, i umiera razem z procesem, który go uruchomił.
• Ma działać, gdy laptop jest zamknięty: wypchnij aplikację na darmowy plan hostingowy. To odłącza aplikację od Twojego laptopa i wprowadza nowe zasady dotyczące kart kredytowych, użytku komercyjnego i tego, czy Twoje dane przetrwają restart.
• Twoja aplikacja nie potrzebuje kodu serwera w momencie żądania: zbuduj ją i umieść statyczny wynik na statycznym hostingu. Może pozostać online bez Twojego laptopa i nie ma żadnego procesu aplikacji do wybudzenia, dopóki konto i limity użycia hosta na to pozwalają.
• Jedno domyślne ustawienie, które warto znać: next dev oraz python -m http.server już nasłuchują na każdym interfejsie sieciowym bez żadnej flagi. Jeśli zakładałeś, że Twój serwer deweloperski jest prywatny i widoczny tylko na laptopie, to nie jest.

Która ścieżka pasuje do Twojej aplikacji

Trzy z tych czterech ścieżek dają aplikacji publiczny adres URL w internecie; pierwsza sięga tylko Twojej własnej sieci, co czyni ją zarazem najszybszą i najbardziej ograniczoną. Posortuj je według tego, jak długo adres URL ma przetrwać, a wybór w zasadzie zrobi się sam.

To, które wiersze są dla Ciebie dostępne, zależy od trzech rzeczy, które możesz sprawdzić we własnym projekcie:

• Czy aplikacja potrzebuje Twojego kodu serwera w momencie żądania? Trasa Flask lub FastAPI, endpoint w server.js albo logika serwera zależna od żądania wymaga hostingu po stronie serwera. Kod serwera wykonywany w czasie builda nie wyklucza automatycznie statycznego wdrożenia: Next.js Server Components mogą działać podczas next build, a statyczne GET Route Handlers można wstępnie wyrenderować. Jeśli każde żądanie w czasie działania da się obsłużyć jako zasoby statyczne lub wysłać bezpośrednio z przeglądarki do zewnętrznego API, ścieżka statyczna wciąż jest otwarta.
• Czy odczytuje lub zapisuje plik, który musi zachować? Plik bazy danych (.db, .sqlite), folder z przesłanymi plikami, plik JSON, który edytuje. Jeśli tak, sprawdź model przechowywania danych hosta przed wdrożeniem. Darmowe usługi webowe Render i darmowe instancje Koyeb używają ulotnego lokalnego magazynu, a Vercel Functions mają system plików tylko do odczytu z tymczasową przestrzenią /tmp . Trwały stan trzymaj w trwałym wolumenie, bazie danych lub magazynie obiektów, zamiast zakładać, że lokalny dysk aplikacji przetrwa.
• Czy potrzebuje sekretu w czasie działania? Klucz w pliku .env działa bez zmian na dwóch pierwszych ścieżkach, bo aplikacja wciąż działa na Twojej maszynie. Na dwóch pozostałych wpisujesz go ponownie w ustawieniach środowiska dostawcy i nie może on leżeć w repozytorium, które wypychasz.

Udostępnij ją we własnej sieci

next dev już nasłuchuje na każdym interfejsie sieciowym Twojej maszyny (właśnie to oznacza 0.0.0.0 , gdy je widzisz), i to samo robi python -m http.server. Żaden z nich nie potrzebuje flagi, więc serwer deweloperski, który masz teraz uruchomiony, prawdopodobnie jest już dostępny z Twojego telefonu w tej samej sieci Wi-Fi.

Next.js dokumentuje -H jako sposób na zmianę tej nazwy hosta, z domyślną wartością 0.0.0.0, a dokumentacja Pythona mówi, że moduł wiąże się ze wszystkimi interfejsami , chyba że przekażesz --bind 127.0.0.1. To czyni tę metodę najszybszym sposobem na udostępnienie aplikacji z localhosta: bez konta, bez instalacji, bez wdrożenia. Innym popularnym serwerom deweloperskim trzeba to powiedzieć wprost.

# 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

Dokumentacja Vite: server.host ma domyślną wartość localhost, a przyjmuje --host w wierszu poleceń lub server.host: '0.0.0.0' w pliku konfiguracyjnym. Uvicorn domyślnie używa 127.0.0.1, co obejmuje FastAPI, bo to on go uruchamia. Streamlit pozostawia server.address nieustawione, a jego dokumentacja konfiguracji zaznacza, że ustawienie go ogranicza dostęp do tego jednego adresu: nieustawione oznacza bez ograniczeń.

Potem potrzebujesz adresu, który przekażesz. To własny adres IP Twojej maszyny w sieci lokalnej, a nie localhost:

# macOS
ipconfig getifaddr en0

# Linux
hostname -I

# Windows (PowerShell)
ipconfig | findstr IPv4

Daj gościowi http://<that-address>:3000 i jest w środku. Haczyk tkwi w kształcie całej ścieżki: ten adres nie znaczy nic poza Twoją siecią. W chwili, gdy gość znajdzie się w innej sieci Wi-Fi, w sieci komórkowej albo w domu, link jest dla niego martwy.

Uwaga: jeśli polecenie działa poprawnie, a drugie urządzenie wciąż nie może się połączyć, prawie zawsze winna jest zapora systemu operacyjnego, nie polecenie. Dokumentacja zapory Apple mówi, że macOS wyświetla alert dla aplikacji, której jeszcze nie zezwoliłeś, i odrzuca połączenie, dopóki nie zareagujesz. Windows z kolei pyta, który profil sieciowy ma zastosowanie, utrzymując osobne reguły dla sieci prywatnych i publicznych . W sieci domowej lub biurowej wybierz Prywatna. Nigdy Publiczna.

Schowaj ją za tunelem

Tunel to mały program, który działa obok Twojej aplikacji i nadaje jej publiczny adres HTTPS. Jedno polecenie daje darmowy tunel do localhosta w około minutę, i warto z góry wiedzieć, że adres URL umiera w chwili, gdy to polecenie się kończy:

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

W routerze nic się nie zmienia, ze względu na kierunek, w którym biegnie połączenie. Twoja maszyna otwiera wychodzące połączenie do brzegu sieci dostawcy, tego samego rodzaju, jakie przeglądarka nawiązuje, by wczytać dowolną stronę, a dostawca trzyma je otwarte i przepycha nim z powrotem żądania przychodzące. Porty przychodzące po Twojej stronie pozostają zamknięte, dlatego działa to w hotelowym Wi-Fi, na hotspocie z telefonu i na łączu domowym, którego routera nie kontrolujesz.

Uwaga: ten ostatni przypadek zasługuje na sześćdziesięciosekundowe sprawdzenie, zanim zamiast tego rozważysz przekierowanie portów. Otwórz stronę stanu routera, znajdź adres IP WAN, który raportuje, i porównaj go ze swoim faktycznym publicznym adresem IP z dowolnej wyszukiwarki „jaki jest mój IP”. Jeśli adres IP WAN mieści się w 100.64.0.0/10, prawdopodobną przyczyną jest CGNAT. Jeśli adres IP WAN i publiczny adres IP po prostu się różnią, wiesz, że wyżej jest kolejna warstwa NAT, ale może to być CGNAT albo zwykły podwójny NAT. W obu przypadkach przekierowanie portów na samym tym routerze może nie wystarczyć. Ten zakres jest zarezerwowany przez RFC 6598 jako współdzielona przestrzeń adresowa, czyli to, za czym stawia Cię dostawca internetu, gdy kończą mu się adresy.

Opcje różnią się głównie tym, czego najpierw od Ciebie chcą.

Szybkie tunele Cloudflare to polecenie powyżej: bez konta, bez domeny, losowa subdomena w trycloudflare.com . Cloudflare ogranicza je do 200 żądań w toku, powyżej tego zwracając 429, nie obsługuje Server-Sent Events i w tej samej dokumentacji mówi, że darmowe tunele są do testów i rozwoju, a nie do wdrażania strony produkcyjnej.

ngrok wymaga najpierw rejestracji, a potem ngrok http 3000. Obecny darmowy plan daje 5 $ jednorazowego wliczonego użycia, które nie odnawia się co miesiąc, do 3 endpointów online, 1 GB transferu, 20 000 żądań HTTP/S i pośrednią stronę z ostrzeżeniem, przez którą gość musi przeklikać. Dostajesz też darmową, automatycznie przydzieloną domenę deweloperską, którą ngrok ogłosił w 2023 roku , by zakończyć starą skargę na adres URL zmieniający się przy każdym restarcie.

localtunnel nie wymaga rejestracji ani instalacji poza npx: npx localtunnel --port 3000. Dostajesz losową subdomenę, a README mówi wprost, że --subdomain prosi o nazwę i jej nie gwarantuje.

localhost.run niczego nie instaluje, bo używa klienta SSH, który Twój system już ma: ssh -R 80:localhost:3000 localhost.run. Dokumentacja zaznacza, że nie trzeba niczego pobierać i że dla darmowych domen nie trzeba zakładać konta.

VS Code ma to w panelu Ports, wygodne, jeśli i tak żyjesz w edytorze. Wymaga logowania przez GitHub lub Microsoft, a domyślne ustawienie Cię podłoży: przekierowany port jest prywatny, co oznacza, że gość zostanie poproszony o zalogowanie się na Twoje konto, dopóki nie przełączysz portu na publiczny. (W porządku dla kolegi z zespołu. Bezużyteczne dla klienta, który chce po prostu kliknąć link.)

Tailscale Funnel też to potrafi, z dwoma ograniczeniami, które zwykle przesądzają sprawę: adres URL może żyć tylko w domenie Twojego tailnetu, a nasłuchiwać może tylko na portach 443, 8443 i 10000.

Cokolwiek wybierzesz, miej jasność, co rozdałeś. Przy publicznym tunelu bez kontroli dostępu wszystko, co serwuje serwer deweloperski, jest dostępne dla każdego, kto ma ten adres URL, w tym trasy, do których nigdy nie linkowałeś, i każdy interfejs debugowania, który zostawiłeś włączony. W porządku na piętnastominutowe demo. Dużo gorzej dla adresu wklejonego na publiczny Discord.

Wygaśnięcie zaskakuje, bo może wyglądać, jakby aplikacja się zepsuła. Większość szybkich ścieżek tutaj wciąż zależy od oprogramowania tunelującego działającego na Twoim laptopie: zatrzymaj cloudflared, ngrok, localtunnel lub sesję SSH localhost.run, a przekierowanie ustaje. Tailscale Funnel jest wyjątkiem, gdy uruchomisz go z --bg, co utrzymuje konfigurację Funnel w tle i przywraca ją po restarcie. Żaden z nich nie obsłuży Twojej lokalnej aplikacji, gdy sam laptop jest offline. Możesz zostawić tunel działający przez wiele dni, i będzie działał dokładnie do chwili, gdy zamknie się klapa albo osiągniesz limit żądań.

Tunel to właściwe narzędzie do demo i niewłaściwe do hostingu: jego dostępność to dostępność Twojego laptopa.

Pozwól aplikacji opuścić Twoją maszynę

To pierwsza ścieżka, na której Twój laptop przestaje być nośny, i pierwsza, na której warunki liczą się bardziej niż narzędzia. Tego, co ją tu kończy, nie wyznacza zegar. To uśpienie, reset systemu plików albo plan, który uzna, że Twoja aplikacja nie jest tym, co chce mieć na darmowej instancji.

Opcje poniżej obejmują zarówno stałe darmowe plany, jak i krótkie okresy próbne. Niektóre potrafią utrzymać aplikację online bezterminowo w ramach swoich limitów; inne zatrzymują się po okresie próbnym o stałej długości albo wymagają płatnego konta za moc obliczeniową. Sprawdź zasady rozliczeń, usypiania i przechowywania danych przed wdrożeniem.

Warunki darmowych planów poniżej sprawdzono na stronach cennika lub dokumentacji każdego dostawcy 7 września 2026 r.

„Nie podano” oznacza, że własne strony dostawcy nie odpowiadają na to pytanie dla darmowego planu. Traktuj to jako niewiadomą, a nie jako tak lub nie.

Trzy z tych wierszy zasługują na dodatkowe spojrzenie, zanim zaczniesz. Fly.io nie ma stałego darmowego planu: okres próbny kończy się po 2 maszynogodzinach lub 7 dniach. Koyeb ma darmową instancję, ale jego proces rejestracji i rozliczeń wymaga uwagi przed wdrożeniem. Hugging Face utrzymuje Static Spaces za darmo, a nowe Spaces Gradio i Docker wymagają płatnego konta, poza ograniczonym wyjątkiem ZeroGPU. Railway nie należy już do tej listy ostrzeżeń: po 30-dniowym okresie próbnym z 5 $ kredytu przechodzi teraz na plan Free za 0 $ z 1 $ kredytu na zasoby miesięcznie.

Potem jest kwestia danych, czyli miejsce, w którym działająca aplikacja po cichu staje się zepsutą. Darmowe usługi webowe Render działają na ulotnym systemie plików, a dokumentacja mówi bez ogródek, że wszystko, co tam zapisano, wyraźnie włączając przesłane obrazy i lokalne bazy SQLite, ginie przy każdym ponownym wdrożeniu, restarcie i uśpieniu. Funkcje Vercel działają na systemie plików tylko do odczytu z jedynie tymczasową przestrzenią roboczą, więc plik SQLite zapisywany przez Twoją aplikację też nie jest tam bezpieczny. Jeśli aplikacja trzyma stan w pliku, przenieś go do trwałego magazynu: hostowanej bazy danych, magazynu obiektów lub trwałego wolumenu tam, gdzie platforma go oferuje.

Uśpienie warto poczuć, zanim się zdecydujesz. W darmowym planie Render 15 minut bezczynności usypia usługę, a kolejne żądanie budzi ją przez około minutę, pokazując stronę ładowania temu, kto kliknął Twój link. Dla pracy w portfolio: wzruszenie ramion. Dla klienta otwierającego link podczas rozmowy: sześćdziesiąt złych sekund.

PythonAnywhere ma subtelniejszą wersję tej pułapki. Nie ma usypiania przy bezczynności, ale darmowa aplikacja webowa wygasa po miesiącu i zatrzymuje się, chyba że klikniesz link odnowienia, który PythonAnywhere wysyła Ci mailem, a darmowe konta mają ograniczony wychodzący dostęp do internetu i sięgają tylko listy dozwolonych hostów zewnętrznych. Aplikacja, która wywołuje API spoza tej listy, stoi sobie w pełni online i zawodzi przy każdym żądaniu do tego niedozwolonego API (okropnie się to debuguje, bo nigdzie nic nie wygląda na niedziałające).

Wydaj ją jako stronę statyczną

Jeśli nic, co robi Twoja aplikacja, nie wymaga kodu serwera w momencie żądania, statyczny hosting jest tu opcją najbliższą „ustaw i zapomnij”: może pozostać online bez Twojego laptopa i nie ma procesu aplikacji czekającego na wybudzenie. Konto i limity użycia hosta nadal obowiązują. Kwalifikuje się więcej aplikacji, niż byś się spodziewał, dlatego na pierwsze z tych trzech pytań warto odpowiedzieć, zanim założysz, że potrzebujesz hostingu po stronie serwera.

Reguła jest węższa niż „czy ma backend”. Twoja aplikacja się kwalifikuje, jeśli każde żądanie, które wysyła, trafia albo do Twoich własnych plików statycznych, albo bezpośrednio z przeglądarki do cudzego API. Pobieranie danych z Supabase czy publicznego API z przeglądarki jest w porządku, z jednym zastrzeżeniem: klucz umieszczony w kodzie przeglądarki to klucz, który opublikowałeś. Drzwi zamyka potrzeba uruchamiania własnego kodu na serwerze przy każdym żądaniu.

Jeśli się kwalifikuje, schemat jest krótki:

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

Następnie wdróż ten wynik builda na statycznym hostingu. Cloudflare Pages, Netlify i Vercel potrafią budować z podłączonego repozytorium. GitHub Pages może publikować pliki statyczne z gałęzi lub użyć GitHub Actions, by uruchomić build Twojego frameworka i wdrożyć wygenerowany wynik.

GitHub Pages ma ograniczenia na tyle ostre, że liczą się od początku. Tylko statyka, jedna strona użytkownika lub organizacji na konto, oraz limity użycia stwierdzające, że to nie darmowy hosting dla biznesu, sklepu e-commerce ani komercyjnego SaaS. Jeśli Twoja aplikacja ma przyjmować płatności, to ją wyklucza, zanim zaczniesz.

Ta ścieżka nie ma wygaśnięcia procesu aplikacji. Działa, dopóki konto hostingowe pozostaje aktywne i w ramach limitów, a przestaje pasować, gdy tylko aplikacja potrzebuje pracy po stronie serwera w momencie żądania.

Gdzie kończą się darmowe ścieżki

Darmowe ścieżki zawodzą w różnych miejscach, nie wszystkie naraz. Statyczny hosting już rozwiązuje kwestię dostępności laptopa i daje stabilny adres URL dostawcy. Darmowy hosting aplikacji potrafi to samo, a niektóre oferują teraz trwały magazyn. VPS zaczyna mieć sens, gdy wymagania się piętrzą: Twój własny proces po stronie serwera musi pozostać online, potrzebujesz przewidywalnego trwałego magazynu, a zasady zasobów lub użycia darmowego planu już nie pasują.

Ten próg warto uszanować. Jedno demo to nie powód, by kupować serwer, podobnie jak statyczny projekt o niskim ruchu. Zostań przy tunelu do krótkotrwałego udostępniania, przy statycznym hostingu, dopóki aplikacja jest naprawdę statyczna, i przy darmowym hostingu aplikacji, dopóki jego limity pasują do tego, co uruchamiasz.

Przejdź na VPS, gdy potrzebujesz zawsze działającego serwera pod własną kontrolą i jesteś gotów wziąć na siebie związaną z tym pracę operacyjną. Nasz Linux VPS to jedna z opcji, a porównywalny VPS od innego dostawcy wykona tę samą robotę. Dobierz rozmiar serwera do aplikacji, zamiast zakładać, że najmniejszy plan wystarczy.

Twórz na VPS Linux z dostępem root, NVMe i mocą AMD EPYC.

Zobacz plany Linux

Po tym zmieniają się dwie rzeczy. Przepływ wdrożeniowy „push do gita”, który dawał hosting platformowy, przestaje być automatyczny. Możesz go odtworzyć za pomocą samodzielnie hostowanego PaaS, takiego jak Coolify lub Dokku, albo zbudować własną ścieżkę CI/CD, i tak czy inaczej aktualizacje i utrzymanie są teraz po Twojej stronie.

Druga zmiana: maszyna mieści więcej niż aplikację. Z przyjemnością będzie uruchamiać Code Server i Claude Code , jeśli wolisz, by Twój edytor też tam mieszkał, co jest albo miłym bonusem, albo całym nowym weekendem pracy, zależnie od Ciebie.

CZYTAJ

Najlepsze self-hostowane alternatywy dla Heroku i Vercel: Coolify, Dokku i inne

Często zadawane pytania