Lokal utvikling domene: pek domenet mot dev-maskinen

Lokal utvikling domene er et ekte domenenavn som peker mot dev-maskinen din i stedet for mot localhost. Det gir deg samme atferd som i produksjon når det gjelder HTTPS, cookies, subdomener og tredjepartsintegrasjoner. Oppsettet tar under ti minutter når du allerede eier et domene.

TL;DR: Registrer et .no-domene, opprett en A-post for et dev-subdomene mot 127.0.0.1 eller din interne IP, sett lav TTL under utvikling, og legg på HTTPS med mkcert eller Caddy. Da kan du teste alt fra cookies til OAuth slik det faktisk blir i produksjon.

Hvorfor droppe localhost i utviklingen?

Nettlesere behandler localhost som en egen, trygg vert. Du får tilgang til kamera, geolokasjon og service workers selv over ren HTTP. Problemet er at det ikke ligner på produksjon, der alt dette krever HTTPS (kryptert forbindelse over nettverket).

Cookies er et annet eksempel. En cookie kan settes på et domene og deles mellom subdomener med Domain-attributtet. Det finnes ingen subdomener under localhost, så du kan aldri teste et oppsett der app.ditdomene.no og api.ditdomene.no deler innlogging.

Også tredjepartstjenester blir vanskelige. Google, GitHub og Stripe krever ofte en nøyaktig matchende redirect-URI i OAuth-innlogging (åpen standard for pålogging til tredjepartstjenester). localhost godtas ikke alltid, og du får uansett ikke testet den virkelige domeneflyten. Med et eget .no-domene fra Feno løser du dette på ett sted.

Lokal utvikling domene: tre måter å koble domenet til maskinen din

Det er tre hovedmåter å bruke et lokal utvikling domene på. Valget handler om hvor mange som skal bruke oppsettet, og hvor fort du trenger endringene.

1. Hosts-filen: raskest, men bare på én maskin

På Linux og macOS redigerer du /etc/hosts, på Windows filen C:\Windows\System32\drivers\etc\hosts. Legg til en linje som denne:

127.0.0.1 dev.ditdomene.no

Nå går nettleseren rett til maskinen din uten å spørre DNS (systemet som oversetter domenenavn til IP-adresser). Endringen er umiddelbar og fungerer uten internett.

Ulempen er at oppsettet bare gjelder på én maskin. Kolleger og testtelefoner må gjøre samme endring hver for seg. Hosts-filen støtter heller ikke wildcard, så du må liste opp hvert subdomene.

2. DNS-post mot et dev-subdomene: deles med hele teamet

Her bruker du vanlig DNS. Opprett en A-post (adresseoppslag som peker et domenenavn mot en IP-adresse) der dev.ditdomene.no peker mot 127.0.0.1. Det smarte er at 127.0.0.1 alltid betyr "denne maskinen", så alle som slår opp domenet får det oversatt til sin egen maskin.

Skal flere utviklere teste mot samme server, eller vil du prøve siden på telefonen, peker du i stedet mot maskinens interne IP, for eksempel 192.168.10.20. Da trenger alle bare tilgang til det lokale nettverket.

3. Wildcard-post: ett oppsett for alle subdomener

En wildcard-post i DNS, for eksempel *.dev.ditdomene.no, sørger for at alle subdomener peker samme sted. Du kan kjøre flere apper, hver på sitt eget subdomene, uten å røre DNS mellom hver endring.

Wildcard finnes ikke i hosts-filen. Trenger du wildcard, må du bruke DNS eller en lokal DNS-server som dnsmasq.

Slik peker du domenet mot dev-maskinen, steg for steg

Her er den konkrete framgangsmåten. Den forutsetter at du har et domene, eller registrerer et nytt.

1. Registrer et domene. Et .no-domene koster fra 99 kroner i året hos Feno. For å registrere trenger du norsk fødselsnummer eller organisasjonsnummer.
2. Opprett en A-post. I Feno sitt kontrollpanel lager du en A-post for subdomenet du vil bruke. Velg type A, skriv for eksempel dev som host, og 127.0.0.1 som verdi. Skal du bruke wildcard, skriver du *.
3. Sett lav TTL. TTL (time to live) forteller hvor lenge et DNS-svar kan lagres i cache. Sett den til 60 eller 300 sekunder mens du utvikler, så treffer endringer nesten umiddelbart.
4. Verifiser oppslaget. Sjekk med dig dev.ditdomene.no +short. Den skal skrive ut IP-adressen du satte. På Windows bruker du nslookup dev.ditdomene.no.
5. Rydd nettlesercache. Gamle svar og service workers kan ligge igjen. Åpne nettstedet i et anonymt vindu for å være sikker.

Pek aldri et dev-oppsett mot en offentlig IP-adresse uten å vite nøyaktig hva du gjør. Hold web-serveren bundet til 127.0.0.1 eller det interne nettverket.

HTTPS lokalt uten advarsler i nettleseren

Når du forlater localhost, mister du statusen som trygg side over ren HTTP. Service workers, geolokasjon og WebAuthn (påloggingsnøkler) slutter å fungere. Du må derfor sette opp HTTPS også i utvikling.

Det enkleste verktøyet er mkcert:

1. Installer mkcert på maskinen.
2. Kjør mkcert -install for å legge den lokale sertifikatmyndigheten din i systemets trust store.
3. Generer sertifikat med mkcert dev.ditdomene.no "*.dev.ditdomene.no".
4. Pek web-serveren mot den genererte sertifikatfilen og nøkkelfilen.

Bruker du Caddy som web-server, får du HTTPS automatisk med intern sertifisering. Sertifikatene fra mkcert er kun gyldige på maskinen din. Det erstatter ikke et offentlig sertifikat for produksjon, men det er akkurat det du trenger i dev.

TTL: derfor tar DNS-endringer tid

DNS-svar lagres i cache i operativsystemet, i ruteren og hos nettverksoperatører. TTL (time to live) forteller hvor lenge et svar skal beholdes. Står den på 3600 sekunder, kan et gammelt svar ligge i en hel time.

Derfor er lav TTL et viktig triks i lokal utvikling. Sett TTL til 60 sekunder i utviklingsperioden og øk den igjen når oppsettet er stabilt. Merk at en resolver som allerede har lagret et svar, holder på det til TTL-en utløper.

Står det helt fast, kan du tømme cachen manuelt: ipconfig /flushdns på Windows, dscacheutil -flushcache på macOS, og sudo systemd-resolve --flush-caches på de fleste Linux-distribusjoner.

Vanlige spørsmål om lokal utvikling med domene

Hvorfor bruke lokal utvikling domene i stedet for localhost?

Fordi localhost ikke oppfører seg som et ekte domene. Du får ikke testet HTTPS-konfigurasjon, cookies på tvers av subdomener, OAuth-innlogging eller tredjepartsintegrasjoner under realistiske forhold. Et ekte domenenavn løser opp mot maskinen din, men oppfører seg som i produksjon.

Er det trygt å peke et .no-domene mot 127.0.0.1?

Ja. 127.0.0.1 betyr alltid "denne maskinen", så adressen kan ikke nås utenfra. Domenet er synlig i det offentlige DNS-systemet, men selve serveren er det ingen som treffer. Det farlige er å peke dev-miljøet mot en offentlig IP eller sette opp port forwarding uten å vite hva du gjør.

Hvorfor ser jeg ikke DNS-endringene med en gang?

Fordi DNS-svar ligger i cache hos flere ledd, ofte med en TTL på flere tusen sekunder. Opprett postene med lav TTL, vent på at gammel cache utløper, eller tøm cachen manuelt. Med TTL på 60 sekunder er det sjelden mer enn et minutts ventetid.

Konklusjon

Et eget domene gjør lokal utvikling mer lik produksjon, og det koster nesten ingenting. Du registrerer et .no-domene fra 99 kroner i året, oppretter en A-post med lav TTL, og legger på HTTPS med mkcert. Hele oppsettet er gjennomført i løpet av en lunsjpause.

Registrer ditt eget .no-domene hos Feno og få DNS, DNSSEC (kryptografisk signering av DNS-svar) og domenelås på samme sted, med transparent prising uten skjulte gebyrer.