Dlaczego profesjonaliści porzucają localhost:3000 na rzecz prawdziwych domen

Wyobraź sobie, że pokazujesz kolegom narzędzie. Zamiast pytać o funkcje, wszyscy patrzą na adres w przeglądarce. "Ile zapłaciłeś za tę domenę?" – pytają. Myślą, że to płatna usługa albo specjalny link. A ja? Nic nie wydałem. Wszystko działało lokalnie na www.mojenarzędzie.pl.

Paradoks wygody w devie

Dzięki frameworkom jak Node.js czy Rails, serwery webowe wbudowane w aplikacje stały się normą. Uruchamiasz npm start i masz stronę na porcie 3000. Zero konfiguracji. Super proste.

Ale ta prostota ma cenę.

Gdy masz kilka projektów – każdy na innym porcie: 3000, 3001, 8080 – tracisz czas na zapamiętywanie numerów. W głowie masz mapę portów, nie kod. W zespole? Chaos gwarantowany.

Najgorsze: lokalne środowisko nie przypomina produkcji. A tam czają się błędy.

Stara szkoła, która wciąż działa

Kiedyś deweloperzy mapowali domeny lokalnie przez plik hosts i reverse proxy. Nie dla lansu. Żeby dev wyglądał jak prod.

Dziś wracamy do tego. Używasz hosts + Nginx. Efekt? Projekty na dev.mojprojekt.pl, qa.mojprojekt.pl. Wygląda pro, ułatwia współpracę i debug.

Jak to ogarnąć krok po kroku

Krok 1: Edytuj plik hosts

Plik hosts to twój prywatny DNS. Dodajesz wpisy, a komputer kieruje je na localhost, bez netu.

Gdzie go znaleźć:

• macOS/Linux: /etc/hosts
• Windows: C:\Windows\System32\Drivers\etc\hosts

Otwórz z prawami admina/sudo. Wpisz:

127.0.0.1 mojprojekt.pl
127.0.0.1 dev.mojprojekt.pl
127.0.0.1 qa.mojprojekt.pl

Teraz przeglądarka wie: te domeny idą na twój komp.

Krok 2: Nginx jako reverse proxy

Aplikacja słucha na 3000, przeglądarka szuka portu 80. Nginx pośredniczy – łapie na 80 i przekierowuje.

Stwórz/edytuj config Nginx (np. w /etc/nginx/sites-available/). Dodaj bloki:

server {
    listen 80;
    server_name mojprojekt.pl;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

server {
    listen 80;
    server_name dev.mojprojekt.pl;

    location / {
        proxy_pass http://localhost:3001;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

server {
    listen 80;
    server_name qa.mojprojekt.pl;

    location / {
        proxy_pass http://localhost:3002;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Restart Nginx:

# macOS
brew services restart nginx

# Linux
sudo systemctl restart nginx

Gotowe. Wpisz mojprojekt.pl – trafi na localhost:3000.

Tip dla WSL2

W WSL2 Linux ma inny IP niż Windows. Sprawdź:

wsl hostname -I

Użyj tego IP w hostsie Windows zamiast 127.0.0.1:

172.x.x.x mojprojekt.pl
172.x.x.x dev.mojprojekt.pl

Dlaczego to ma sens

To nie kosmetyka. To solidne podstawy.

Parity środowisk. Dev z reverse proxy jak w prod. Błędy wychodzą od razu.

Komunikacja w teamie. "Wejdź na dev.mojprojekt.pl" – jasne i bez pomyłek.

Czysty umysł. Zapominasz o portach. Działasz jak w realu.

A przede wszystkim: odróżniasz się od amatorów. Profesjonaliści budują workflow na lata.

Umiejętność na zawsze

Ta metoda jest stara jak internet, ale zapomniana przez wygodę. A wygoda to nie profesjonalizm.

Poświęć 20 minut na setup. Oszczędzisz godziny frustracji. Skupisz się na kodzie, nie na portach.

Następnym razem, gdy ktoś zapyta o localhost:3000, powiedz: "Bo myślę jak pro.