Private networking en .internal-domeinen op Dockup

Private networking zorgt ervoor dat services en beheerde databases binnen één Dockup-project met elkaar kunnen communiceren zonder verkeer binnen hetzelfde project over het openbare internet te sturen. Elke resource krijgt een stabiele hostnaam in de vorm van <slug>.internal, terwijl afzonderlijke projecten van elkaar geïsoleerd blijven.

Het netwerk is opt-in. Als je het inschakelt, worden bestaande projectresources verbonden zonder dat applicatieverkeer direct moet overschakelen. Na een nieuwe deployment ontvangen services interne connection variables.

Hoe vermindert service-to-service networking de blootstelling aan het openbare internet?

Een openbaar database-endpoint is bereikbaar vanaf het internet, ook wanneer authenticatie onbevoegd gebruik blokkeert. Een private route verwijdert die blootstelling voor applicatieverkeer en geeft services een stabiele interne naam die niet afhankelijk is van een openbaar adres.

D hetzelfde principe geldt voor aanroepen van service naar service. Een API kan een worker, interne adminservice of backend aanroepen via het projectnetwerk in plaats van via een openbaar custom domain.

Verkeerspad	Openbare route	Private route
API naar PostgreSQL	Openbare host en poort	main-db.internal
Web naar API	Openbaar custom domain	api.internal
Worker naar Redis	Openbare host en poort	app-redis.internal
Preview naar productiedatabase	Openbare databasecredential	Interne gebruiker met alleen-lezenrechten
Aanroep tussen projecten	Openbaar endpoint vereist	Geblokkeerd door projectisolatie

Private betekent niet zonder authenticatie. Blijf databasegebruikers, service authorization en secrets gebruiken. Het netwerk bepaalt de bereikbaarheid; credentials bepalen de rechten.

Hoe schakel je private networking voor een project in?

Schakel het netwerk in voor de project-slug:

dockup network enable production --json

Deze bewerking verbindt services en beheerde databases met het projectnetwerk. Bestaande openbare listeners blijven standaard beschikbaar, zodat je de overstap geleidelijk kunt maken.

Voer voor elke applicatieservice die interne environment variables moet ontvangen een nieuwe deployment uit:

dockup deploy production/api --wait --json
dockup deploy production/worker --wait --json

Dockup injecteert connection data zoals DATABASE_URL_INTERNAL, databasespecifieke interne URL- en hostvariabelen en host-/poortwaarden van services. Bekijk de environment keys van de service zonder secrets bloot te geven:

dockup env list -s production/api --json

Stel een URL niet handmatig samen op basis van een weergavenaam. Resource-slugs bepalen de hostnaam <slug>.internal.

Controleer voordat je de applicatieconfiguratie wijzigt of elke dependency in hetzelfde project staat. Afzonderlijke projecten hebben afzonderlijke netwerken en kunnen elkaar niet via het interne pad resolven of bereiken.

Hoe veranderen .internal-domeinen de serviceconfiguratie?

Interne DNS biedt een stabiele naam terwijl containers en nodes op de achtergrond veranderen. Een API-service met de slug api is bereikbaar als api.internal vanuit services in hetzelfde project; een database met de slug main-db is bereikbaar als main-db.internal.

Gebruik bij voorkeur de geïnjecteerde connection variables wanneer die beschikbaar zijn. Deze bevatten het juiste protocol, de juiste credentials, databasenaam en hostindeling. Een zelf samengestelde string kan TLS, password encoding of databaseparameters weglaten.

Migreer één dependency tegelijk:

1. Schakel het netwerk in.
2. Voer een nieuwe deployment uit van de consumerende service.
3. Controleer of de interne variabele bestaat.
4. Wijzig de applicatie zodat die de variabele gebruikt.
5. Deploy met --wait.
6. Controleer nieuwe verbindingen.
7. Bekijk runtime logs en responstijd.
8. Ga door met de volgende dependency.

Een service kan zijn openbare custom domain behouden voor gebruikersverkeer en tegelijk private hostnames gebruiken voor backend-aanroepen. Openbare en private paden bedienen verschillende trust boundaries.

De handleiding environment variables en secrets legt uit waarom wijzigingen in verbindingen een nieuwe deployment vereisen.

Hoe maak je een beheerde database alleen privé toegankelijk?

Verwijder de public listener nadat elke vereiste consumer het interne pad gebruikt:

dockup db private production/main-db --json

Herstel openbare plus private toegang wanneer dat nodig is:

dockup db private production/main-db --off --json

Deze databasebewerking maakt de container opnieuw aan en behoudt de data. Plan een maintenance window dat past bij de workload, controleer of er een recente backup is en test of de applicatie opnieuw verbinding kan maken.

Controleer het volgende voordat je de database alleen privé toegankelijk maakt:

• Elke productieservice die de database gebruikt, bevindt zich in hetzelfde project.
• Operationele tools hebben het openbare endpoint niet nodig.
• Previewtoegang gebruikt het ondersteunde private pad.
• Er is een backup beschikbaar en recovery is begrepen.
• Connection pools voeren veilig nieuwe pogingen uit.
• Het exacte doel project/db is vastgelegd.

Een database die alleen privé toegankelijk is, kan niet rechtstreeks vanaf de laptop van een operator via het openbare internet worden bereikt. Gebruik ondersteunde platformtoegang en diagnostiek op applicatieniveau in plaats van de listener zonder meer opnieuw te openen.

Zie managed PostgreSQL voor databasebewerkingen.

Hoe krijgen PR-previews veilig toegang tot productiedata?

Elke Dockup PR- of branch-preview krijgt een eigen geïsoleerde deployment en URL. In een project met private networking maakt de preview deel uit van het projectnetwerk en kan deze <slug>.internal resolven.

Dockup maakt automatisch een gebruiker met alleen-lezenrechten aan voor de beheerde productiedatabase die door de preview wordt gebruikt. De preview kan data in de vorm van productiegegevens opvragen, maar kan via deze gebruiker niets schrijven.

Dit ontwerp verkleint het risico dat een feature branch klantgegevens wijzigt, maar leestoegang heeft nog steeds gevolgen:

• Persoonlijke of gevoelige data kan in de preview verschijnen.
• Nieuwe applicatiecode kan opgevraagde data loggen.
• Een kwetsbare preview-URL kan leesresultaten blootleggen.
• Zware queries kunnen de productieload beïnvloeden.
• Schema-aannames kunnen verschillen tussen branch en productie.

Schakel previewdeployment alleen in volgens een beoordeeld beleid:

dockup pr-preview production/api --on --json
dockup preview branch feature/search production/api --json

Gebruik de geïsoleerde omgeving van de preview voor feature flags en secrets die niet met de database te maken hebben. Vervang de automatische read-only credential niet door de productiecredential met schrijfrechten.

Hoe observeer en troubleshoot je private networking?

Begin met de topologie en configuratie in plaats van direct uit te gaan van een platformstoring.

Symptoom	Waarschijnlijk gebied	Controle
Naam niet gevonden	Verkeerde slug of verkeerd project, of service niet opnieuw gedeployed	Servicelijst en env keys
Verbinding geweigerd	Resource gestopt of verkeerde poort	Status en logs van database/service
Authenticatie mislukt	Verkeerde credential	Secret rotation en gebruiker
Openbaar werkt, privé werkt niet	Interne variabele of ingebruikname van het netwerk	Netwerk inschakelen, opnieuw deployen
Preview kan lezen maar niet schrijven	Verwacht read-onlybeleid	Credential niet vervangen
Aanroep tussen projecten mislukt	Verwachte isolatie	Gebruik een openbare, geauthenticeerde API

Bekijk de runtime logs van de applicatie:

dockup logs production/api --json

Bekijk de databaseomvang en connection errors van de applicatie:

dockup db size production/main-db --json
dockup logs production/api --json

Print volledige interne connection URLs niet in incidentnotities. Ze kunnen credentials bevatten, ook al is de hostnaam zelf geen secret.

Migratie- en rollbackplan

Houd de public listener tijdens de eerste fase actief. Als de interne deployment mislukt, herstel je de vorige configuratie van de applicatie en voer je opnieuw een deployment uit. Maak de database pas alleen privé toegankelijk nadat het interne pad stabiel is gebleken.

Schakel het volledige projectnetwerk uit met:

dockup network disable production --json

Dit moet een bewuste rollback zijn en niet de eerste troubleshootingstap. Het uitschakelen van het netwerk beïnvloedt elke verbonden resource in het project.

Leg wijzigingen aan het netwerk vast via het auditlog:

dockup audit --writes --json

Checklist voor private networking in productie

Een compleet runbook voor private networking bevat de project-slug, slugs van services en databases, interne hostnames, namen van geïnjecteerde variabelen, beleid voor public listeners, beleid voor previewtoegang, backupstatus, volgorde van redeployments en het rollbackpad.

CPU, RAM en disk blijven usage-based en worden per minuut gemeten; private routing is een architectuurkeuze en geen vaste instance class. Gebruik PaaS-pricing uitgelegd voor kostenmodellen.

De Dockup CLI-reference bevat de actuele netwerk- en databaseopdrachten. Zie security best practices voor algemene deploymentisolatie.

Modelleer service authorization los van bereikbaarheid

Een interne hostname bewijst alleen dat de aanroeper zich op het projectnetwerk bevindt. De hostname bewijst niet welke service het verzoek heeft gedaan of of die service de actie mag uitvoeren. Behoud applicatie-authenticatie voor gevoelige interne API's en databasecredentials voor datatoegang.

Gebruik servicespecifieke secrets in plaats van één gedeeld intern token. Als een preview read-only databasetoegang krijgt, geef deze dan niet ook een productieservicetoken waarmee via een API schrijfbewerkingen kunnen worden uitgevoerd.

Meet het effect van de overstap

Vergelijk connection latency, error rate en p95-responstijd voordat en nadat je overschakelt op interne endpoints. Het primaire doel is isolatie en een stabiel privaat pad; eventuele verbetering in latency moet worden gemeten en niet worden beloofd.

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

Bewaar het observatievenster en de deployment-ID. Zo krijgt de wijziging naar private networking een meetbaar voltooiingscriterium in plaats van te eindigen bij “DNS is opgelost”.

Documenteer uitzonderingen op het openbare pad

Sommige externe integraties, operator-tools of services uit andere projecten hebben mogelijk nog een openbaar endpoint nodig. Noteer elke uitzondering, de authenticatie, de eigenaar en de voorwaarde voor verwijdering. Zo voorkom je dat de public listener onbeperkt actief blijft omdat niemand meer weet waarom deze bestaat.

Een volledige uitrol van private networking kan gedeeltelijk zijn, maar elk openbaar pad moet bewust gekozen zijn.

Controleer interne dependencies na hernoemingen

Een hernoeming of vervanging van een resource kan de slug wijzigen die voor .internal-adressering wordt gebruikt. Inventariseer consumers voordat je namen wijzigt, deploy ze opnieuw met bijgewerkte geïnjecteerde variabelen en controleer elke private verbinding.

Zo blijft private networking stabiel terwijl het project zich ontwikkelt.

Begin met een verifieerbare deployment

Schakel networking in voor een niet-productieproject, migreer één dependency naar het .internal-endpoint en bewijs dat het rollbackpad werkt voordat je een public listener verwijdert.

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

FAQ

Welke hostname gebruiken Dockup-resources op het private netwerk?

Elke service en beheerde database in hetzelfde project is bereikbaar via een stabiele hostname in de vorm <slug>.internal.

Verwijdert het inschakelen van private networking de openbare databasetoegang?

Nee. Het netwerk is standaard een aanvulling. Gebruik de afzonderlijke databaseopdracht private om de public listener te verwijderen nadat consumers het interne pad gebruiken.

Kunnen verschillende Dockup-projecten elkaar privé bereiken?

Nee. Elk project heeft een geïsoleerd netwerk. Communicatie tussen projecten moet daarom via een geschikte openbare en geauthenticeerde interface verlopen.

Kan een PR-preview naar de productiedatabase schrijven?

In een project met private networking maakt Dockup automatisch een databasegebruiker met alleen-lezenrechten voor de preview aan. Daarmee kan de preview lezen, maar niet schrijven via die credential.

Waarom moeten services opnieuw worden gedeployed nadat networking is ingeschakeld?

Een nieuwe deployment geeft de nieuwe container de interne connection variables en zorgt ervoor dat de applicatie start met de configuratie voor het private endpoint.