Waarom pro-ontwikkelaars localhost:3000 vaarwel zeggen voor echte domeinnamen

Vorige week liet ik een intern tooltje zien aan het team. De tool zelf? Die kreeg amper aandacht. Iedereen zoomde in op één ding: "Hoeveel heb je voor die domeinnaam betaald?" De een dacht dat ik 'm speciaal voor de demo had gekocht. De ander vermoedde dat hun IP op een whitelist stond.

Niets van dat alles. Ik draaide alles lokaal, gewoon op www.internaltool.com in plaats van localhost:3002. Gratis en professioneel.

Het probleem met snelle dev-servers

Dankzij frameworks als Node.js en Rails starten we apps razendsnel op met npm start. Direct live op poort 3000. Geen gedoe met servers of config.

Handig, maar niet zonder nadelen.

Met drie of vier projecten tegelijk jongleer je poorten: 3000, 3001, 8080, 5173. Je hersens veranderen in een poort-rooster. Code schrijven? Vergeet het maar. En in een team? Chaos.

Erger nog: je lokale setup lijkt totaal niet op production. Daar sluipen bugs in.

De klassieke truc die altijd werkt

Vroeger, voor ingebouwde servers, gebruikten developers echte domeinnamen lokaal. Via de hosts file en een reverse proxy als Nginx.

Niet alleen voor de looks. Het bootst production na, recht op je machine.

Resultaat? Schone URLs als dev.jouwpproject.com of qa.jouwpproject.com. Allemaal naar lokale poorten. Makkelijker samenwerken, helderder hoofd, en een setup die matcht met live.

Zo stel je lokale custom domains in: stap voor stap

Stap 1: Pas je hosts file aan

De hosts file is je privé-DNS. Voeg entries toe, en je machine zoekt niet op internet voor die domeinen.

Locatie:

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

Open met sudo of als admin. Voeg toe:

127.0.0.1 myproject.com
127.0.0.1 dev.myproject.com
127.0.0.1 qa.myproject.com

Nu resolven browsers deze naar localhost.

Stap 2: Nginx als reverse proxy

Je app draait op poort 3000, maar browsers verwachten poort 80. Nginx vangt traffic op en stuurt door.

Maak een config in /etc/nginx/sites-available/ (of waar jij Nginx hebt). Voeg server blocks toe:

server {
    listen 80;
    server_name myproject.com;

    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.myproject.com;

    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.myproject.com;

    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;
    }
}

Herstart Nginx:

# macOS
brew services restart nginx

# Linux
sudo systemctl restart nginx

Klaar. Surf naar myproject.com en je zit op localhost:3000 via een echte domein.

Tip voor WSL2-gebruikers

In WSL2 heeft Linux een apart IP. Pak het met:

wsl hostname -I

Output zoals 172.x.x.x. Gebruik dat IP in je Windows hosts file, niet 127.0.0.1.

Waarom dit écht verschil maakt

Lijkt cosmetisch? Nee.

Eerst: parity met production. Reverse proxy lokaal? Bugs die online opduiken, vind je nu meteen.

Tweede: teamwerk. Zeg "ga naar dev.internaltool.com" in plaats van "poort 3000". Duidelijker, professioneler.

Derde: focus. Geen poort-geheugen meer. Gewoon surfen als in het echt.

En het belangrijkste: niveau omhoog. Dit scheidt serieuze devs van hobbyisten. Je workflow wordt scalable.

Een timeless skill voor je toolkit

Deze methode bestaat al jaren, maar raakt ondergesneeuwd door gemak. Toch is gemak niet alles.

Investeer 20 minuten hierin. Beste tijd voor je dev-flow deze maand. Zo focus je op code, niet op poorten.

Volgende keer als iemand vraagt waarom geen localhost:3000, zeg je: "Omdat ik pro denk.