Aangepast domein en automatische TLS op Dockup

Een configuratie met een aangepast domein en automatische TLS bestaat uit drie afzonderlijke lagen: de Dockup-service moet gezond zijn, DNS moet de hostname naar het platform laten verwijzen en de hostname moet worden geverifieerd voordat er een certificaat kan worden uitgegeven. Door deze lagen afzonderlijk te behandelen, wordt de omschakeling voorspelbaar en voorkom je dat DNS-fouten worden aangezien voor applicatiefouten.

Dockup geeft elke service ook een *.dockup.tech-adres. Houd dat adres beschikbaar tijdens de DNS-propagatie, zodat je de applicatie onafhankelijk van de aangepaste hostname kunt testen.

Wat moet klaarstaan voordat je een aangepast Dockup-domein toevoegt?

Begin met een service die al draait en de readiness gate doorstaat:

dockup status production/web --json
dockup health production/web --json

Open of test de bestaande *.dockup.tech-URL. Als de applicatie daar al problemen geeft, lost het toevoegen van een domein dat niet op. Bekijk eerst de runtime-logs.

Verzamel de volgende informatie:

Item	Voorbeeld	Waarom dit belangrijk is
Exact doel	production/web	Voorkomt dat je het domein aan de verkeerde service koppelt
Hostname	app.example.com	De DNS-naam die gebruikers bezoeken
DNS-toegang	Registrar of DNS-provider	Nodig om het record aan te maken
Huidige TTL	300 seconden	Bepaalt de snelheid van propagatie en rollback
Canonieke URL van de applicatie	https://app.example.com	Kan redirects en cookies beïnvloeden
Health-route	/health	Bevestigt dat de service klaar is vóór de omschakeling

Verlaag vooraf de bestaande DNS-TTL wanneer je een live provider vervangt. Verwijder het oude record pas nadat het Dockup-doel, de applicatieconfiguratie en het rollbackplan bekend zijn.

Controleer applicatiegedrag dat afhankelijk is van de host. Authenticatie-callbacks, CORS-allowlists, cookiedomeinen, OAuth redirect-URL's, webhookbestemmingen en gegenereerde absolute links moeten mogelijk worden aangepast aan de nieuwe HTTPS-hostname.

Hoe voeg je het domein toe en verifieer je het?

Bekijk eerst de huidige domeinen:

dockup domain list production/web --json

Voeg de hostname toe:

dockup domain add app.example.com production/web --json

De response bevat het DNS-doel dat moet worden geconfigureerd. Maak het aangegeven CNAME-record aan bij de DNS-provider. Verzin geen IP-adres en kopieer geen waarde van een andere service; gebruik het doel dat voor dit domein is geretourneerd.

Nadat de DNS-propagatie is voltooid, verifieer je het domein met de geretourneerde domein-ID:

dockup domain verify <domainId> production/web --json

De verificatie bevestigt dat het openbare DNS-record correct wordt opgelost. Een fout betekent meestal een van vier dingen:

1. De recordnaam is onjuist.
2. Het CNAME-doel is onjuist.
3. Er bestaat nog een oud conflicterend A-, AAAA- of CNAME-record.
4. Resolvercaches hebben de nieuwe waarde nog niet overgenomen.

Controleer de authoritative DNS in plaats van het domein steeds opnieuw te verwijderen en aan te maken. Propagatie is een gedistribueerd cacheproces, geen Dockup-buildproces.

Hoe wordt het HTTPS-certificaat uitgegeven en beheerd?

Vraag het certificaat aan zodra de verificatie is geslaagd:

dockup domain ssl <domainId> production/web --json

Dockup verzorgt de certificaatuitgifte voor de geverifieerde hostname en serveert het aangepaste domein via HTTPS. Het platform beheert de TLS-lifecycle, zodat de applicatiecontainer geen certificaatbestanden hoeft op te slaan en geen renewalproces hoeft uit te voeren.

Valideer het resultaat van buiten het platform:

curl -I https://app.example.com

Controleer of:

• Het certificaat overeenkomt met de hostname.
• De response via HTTPS wordt geleverd.
• Redirects niet in een lus terechtkomen.
• De applicatie de verwachte status retourneert.
• Authenticatie- en callbackflows de nieuwe origin gebruiken.
• Statische assets zonder mixed-contentfouten worden geladen.

Certificaatuitgifte kan mislukken terwijl de applicatie zelf gezond is. Houd DNS-diagnose en servicediagnose gescheiden. Gebruik domain verify voor DNS-eigendom en de servicelogs voor applicatiegedrag.

Het artikel over zero-downtime deployments beschrijft de onafhankelijke release-readiness gate.

Hoe schakel je verkeer om zonder downtime?

Bij een veilige omschakeling blijft het oude pad beschikbaar totdat de nieuwe hostname is bewezen.

1. Deploy en verifieer de Dockup-service via de platform-URL.
2. Voeg het aangepaste domein toe in Dockup.
3. Maak het DNS-record aan.
4. Verifieer DNS.
5. Geef TLS uit.
6. Test HTTPS rechtstreeks.
7. Werk callbacks, canonieke URL's en monitoring bij.
8. Stuur een klein deel van het operationele verkeer via de nieuwe route als de DNS-configuratie dat toestaat.
9. Houd logs en uptime in de gaten.
10. Schakel de oude provider pas uit nadat het nieuwe pad stabiel is.

Dockup-uptimechecks worden elke minuut uitgevoerd en rapporteren statistieken over de responstijd, waaronder p95:

dockup uptime production/web --hours 24 --json

Gebruik voor kritieke domeinen daarnaast onafhankelijke externe monitoring. Een platformprobe bevestigt publieke bereikbaarheid, terwijl een externe monitor het gebruikerspad vanaf een ander systeem controleert.

Als het aangepaste domein een huidige productiehost vervangt, leg dan een rollbackrecord vast: de vorige DNS-waarde, de vorige TTL, de status van de oude provider en de voorwaarde die een rollback activeert.

Hoe werken domeinen voor extra poorten?

Een service kan een tweede HTTP-poort beschikbaar stellen voor een admin-UI, metrics-endpoint of ander webproces. Dockup kan hiervoor een extra platformdomein aanmaken zonder aangepaste DNS:

dockup port list production/web --json
dockup port add 8080 production/web --name admin --json

Het geretourneerde domein verwijst naar de geselecteerde containerpoort. Dit staat los van het hoofddomein.

Stel een poort niet alleen beschikbaar omdat er een proces op luistert. Ga na of het endpoint authenticatie gebruikt, of het productiegegevens bevat en of het überhaupt openbaar moet zijn. Een interne admininterface mag niet voor het gemak toegankelijk worden vanaf het internet.

Verwijder een verouderd poortdomein uitsluitend via de ondersteunde domeininterface, nadat je hebt gecontroleerd dat geen monitor, callback of operatorworkflow het nog gebruikt. Wijzigingen aan poortdomeinen zijn mutaties en verschijnen in het auditlog.

Hoe los je DNS-, TLS- en applicatiefouten op?

Gebruik een diagnose per laag:

Symptoom	Eerste controle	Dockup-opdracht
Domein wordt niet opgelost	DNS-record en propagatie	domain verify
Certificaat wordt niet uitgegeven	Status van domeinverificatie	domain list, domain ssl
HTTPS werkt, maar de applicatie geeft fouten	Runtime-logs	logs --json
Redirectlus	Proxy-/hostinstellingen van de applicatie	env list, runtime-logs
Platform-URL werkt, aangepaste host niet	DNS-/TLS-laag	Domeinopdrachten
Beide URL's werken niet	Deployment en runtime	status, build-/runtime-logs
Secundaire poort werkt niet	Poortdomeintoewijzing en proces	port list, runtime-logs

Bekijk de service-output zonder die te vermengen met DNS-conclusies:

dockup logs production/web --json
dockup status production/web --json

Als een recente wijziging van de environment een canonieke URL heeft toegevoegd, moet je eraan denken dat hiervoor een nieuwe deployment nodig is:

dockup env set APP_URL=https://app.example.com \
  -s production/web \
  --json

dockup deploy production/web --wait --json

De handleiding voor environment variables en secrets beschrijft die lifecycle.

Domein verwijderen en rollback

Het verwijderen van de Dockup-koppeling is destructief voor de route. Verplaats of verwijder daarom eerst het openbare DNS-record en bevestig de beoogde vervanging. Verwijder daarna de koppeling via de ondersteunde domeininterface met de exacte domein-ID.

Verwijder het domein niet tijdens een tijdelijke certificaat- of propagatiestoring, tenzij het herstelplan dat vereist. Als de configuratie blijft staan, kan de verificatie slagen zodra de caches zijn bijgewerkt.

Bekijk mutaties met:

dockup audit --search domains --json

Het audittrail moet tonen wie de hostname heeft toegevoegd, geverifieerd, beveiligd of verwijderd.

Checklist voor overdracht naar productie

Een volledige overdracht van aangepast domein en automatische TLS bevat het servicedoel, de hostname, de domein-ID, het type en doel van het DNS-record, het verificatieresultaat, het certificaatresultaat, wijzigingen aan applicatiecallbacks, de monitoring-URL en de DNS-waarde voor rollback.

Sla geen private certificaatsleutel op in de repository of container. De managed TLS-grens van Dockup bestaat juist zodat het applicatieteam de hostname kan beheren zonder certificaatmateriaal te distribueren.

Gebruik voor alle actuele flags de Dockup CLI reference. Volg voor de eerste deployment vóór het domeinwerk Van Git-repository naar productie.

Plan keuzes voor apex en subdomeinen

Een subdomein zoals app.example.com is meestal de eenvoudigste applicatiehostname, omdat DNS-providers dit met een CNAME kunnen weergeven. Voor een apex zoals example.com kan provider-specifieke flattening of aliasfunctionaliteit nodig zijn. Volg het DNS-doel dat Dockup retourneert en de mogelijkheden van de authoritative DNS-provider.

Kies één canonieke host en stuur alternatieven door op applicatie- of routingniveau. Als je zowel www als de apex aanbiedt zonder canoniek beleid, kunnen cookies, analytics, cache-items en zoekindexering worden opgesplitst.

Test aannames over certificaatvernieuwing

Managed TLS maakt het onnodig om een renewalclient in de container te draaien, maar de hostname moet correct blijven resolven. Een toekomstige DNS-migratie, proxywijziging of verwijderd record kan de validatie verstoren.

Neem de domeinstatus op in periodieke controles:

dockup domain list production/web --json
dockup uptime production/web --hours 24 --json

In het runbook voor aangepast domein en automatische TLS moeten de DNS-eigenaar, het renewalcontact en de datum van de laatste externe certificaatcontrole staan. Zo ontdek je eigenaarschap niet pas wanneer er een certificaatincident optreedt.

Bescherm niet-productiehostnames

Staging- en preview-hostnames kunnen onafgemaakte functies en gegevens met een productievorm blootleggen. Gebruik waar nodig authenticatie in de applicatie, definieer een indexingbeleid op applicatieniveau en beperk de verspreiding van niet-productie-URL's.

Instructies voor zoekmachines zijn geen toegangscontrole. Een beveiligde omgeving heeft nog steeds authenticatie en passende omgang met gegevens nodig.

Controleer opnieuw na propagatie

Herhaal externe HTTPS- en callbacktests nadat de oorspronkelijke DNS-TTL volledig is verstreken.

Begin met een verifieerbare deployment

Koppel eerst een niet-kritieke hostname, behoud de platform-URL tijdens de propagatie en noteer de exacte DNS-waarde die nodig is voor rollback.

Start gratis op app.dockup.ai. Het Free-plan kost $0 per maand, bevat een starttegoed van $10 en ondersteunt één workspace, drie databases en drie deployments.

Veelgestelde vragen

Welk DNS-record heeft een aangepast Dockup-domein nodig?

Voer dockup domain add uit en maak het DNS-record aan dat in de response wordt weergegeven. Gebruik het geretourneerde doel in plaats van een waarde van een andere service te kopiëren.

Wanneer kan Dockup TLS uitgeven voor een aangepast domein?

Nadat het DNS-record van de hostname de Dockup-domeinverificatie heeft doorstaan, vraag je certificaatuitgifte aan met de gedocumenteerde opdracht domain ssl.

Moet mijn container TLS-certificaten opslaan?

Nee. Dockup beheert TLS voor het geverifieerde aangepaste domein. De applicatiecontainer heeft daarom geen certificaatbestanden of renewalproces nodig.

Kan Dockup een extra containerpoort beschikbaar stellen?

Ja. Met de port-opdrachten kun je een afzonderlijk automatisch gegenereerd domein maken voor een extra openbare poort, zonder aangepaste DNS te configureren.

Wat moet ik controleren als de platform-URL werkt, maar het aangepaste domein niet?

Richt je op DNS-records, propagatie, domeinverificatie en certificaatstatus. De werkende platform-URL laat zien dat de applicatielaag waarschijnlijk goed werkt.