Privat nätverk och .internal-domäner på Dockup

Privata nätverk gör att tjänster och hanterade databaser i samma Dockup-projekt kan kommunicera utan att trafik inom projektet skickas över det offentliga internet. Varje resurs får ett stabilt värdnamn på formen <slug>.internal, medan separata projekt förblir isolerade från varandra.

Nätverket är opt-in. När du aktiverar det ansluts befintliga resurser i projektet utan att applikationstrafiken omedelbart måste byta väg, och tjänsterna får interna anslutningsvariabler efter en ny deployment.

Hur minskar service-to-service-nätverk exponeringen mot det offentliga internet?

En publik databasslutpunkt kan nås från internet även när autentisering förhindrar obehörig användning. En privat route tar bort denna exponering för applikationstrafik och ger tjänsterna ett stabilt internt namn som inte beror på en publik adress.

Samma princip gäller anrop mellan tjänster. Ett API kan anropa en worker, en intern administratörstjänst eller en backend över projektnätverket i stället för via en publik custom domain.

Trafikväg	Publik route	Privat route
API till PostgreSQL	Publik host och port	main-db.internal
Webb till API	Publik custom domain	api.internal
Worker till Redis	Publik host och port	app-redis.internal
Preview till produktionsdatabas	Publik databasinloggning	Skrivskyddad intern användare
Anrop mellan projekt	Publik slutpunkt krävs	Blockeras av projektisolering

Privat betyder inte oautentiserat. Fortsätt använda databas användare, behörighetskontroller för tjänster och secrets. Nätverket avgör nåbarhet; autentiseringsuppgifter avgör behörighet.

Hur aktiverar du privata nätverk för ett projekt?

Aktivera nätverket för projektets slug:

dockup network enable production --json

Åtgärden ansluter tjänster och hanterade databaser till projektnätverket. Befintliga publika listeners är tillgängliga som standard, så övergången kan ske stegvis.

Gör en ny deployment av varje applikationstjänst som ska få interna miljövariabler:

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

Dockup injicerar anslutningsdata som DATABASE_URL_INTERNAL, databasspecifika interna URL- och host-variabler samt host- och portvärden för tjänster. Inspektera tjänstens miljövariabelnamn utan att exponera secrets:

dockup env list -s production/api --json

Bygg inte manuellt en URL från ett visningsnamn. Resursernas slug avgör värdnamnet <slug>.internal.

Innan du ändrar applikationskonfigurationen ska du verifiera att alla beroenden finns i samma projekt. Separata projekt har separata nätverk och kan inte slå upp eller nå varandra via den interna vägen.

Hur förändrar .internal-domäner tjänsternas konfiguration?

Intern DNS ger ett stabilt namn även när containers och noder byts ut bakom kulisserna. En API-tjänst med slug api nås som api.internal från tjänster i samma projekt; en databas med slug main-db nås som main-db.internal.

Använd helst de injicerade anslutningsvariablerna när de finns tillgängliga. De innehåller rätt protokoll, autentiseringsuppgifter, databasnamn och host-format. En manuellt byggd sträng kan sakna TLS, korrekt lösenordskodning eller databasparametrar.

Migrera ett beroende i taget:

1. Aktivera nätverket.
2. Gör en ny deployment av tjänsten som använder beroendet.
3. Bekräfta att den interna variabeln finns.
4. Ändra applikationen så att den använder variabeln.
5. Deploya med --wait.
6. Verifiera nya anslutningar.
7. Följ runtime-loggar och svarstid.
8. Fortsätt med nästa beroende.

En tjänst kan behålla sin publika custom domain för användartrafik och samtidigt använda privata värdnamn för backend-anrop. Publika och privata vägar har olika trust boundaries.

Guiden miljövariabler och secrets förklarar varför ändringar av anslutningar kräver en ny deployment.

Hur gör du en hanterad databas enbart privat?

När alla nödvändiga konsumenter använder den interna vägen tar du bort den publika listen­ern:

dockup db private production/main-db --json

Återställ publik och privat åtkomst när det behövs:

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

Den här databasåtgärden återskapar containern samtidigt som data bevaras. Planera ett maintenance window som passar arbetsbelastningen, bekräfta att en aktuell backup finns och testa att applikationen kan återansluta.

Kontrollera följande innan du gör databasen enbart privat:

• Alla produktionstjänster som använder databasen finns i samma projekt.
• Operativa verktyg kräver inte den publika slutpunkten.
• Preview-åtkomst använder den stödda privata vägen.
• En backup finns och återställningen är förstådd.
• Connection pools försöker ansluta igen på ett säkert sätt.
• Det exakta målet project/db är dokumenterat.

En enbart privat databas kan inte nås direkt från en operatörs laptop över det publika internet. Använd plattformens stödda åtkomst och diagnostik på applikationsnivå i stället för att slentrianmässigt öppna listen­ern igen.

För databasåtgärder, se hanterad PostgreSQL.

Hur får PR-previews säker åtkomst till produktionsdata?

Varje Dockup PR- eller branch-preview får en egen isolerad deployment och URL. I ett projekt med privata nätverk ansluts previewn till projektnätverket och kan slå upp <slug>.internal.

Dockup skapar automatiskt en skrivskyddad användare för den produktionsdatabas som previewn använder. Previewn kan läsa data med samma struktur som i produktion, men kan inte skriva med den användaren.

Den här designen minskar risken för att en feature branch ändrar kundposter, men läsåtkomst får fortfarande konsekvenser:

• Personuppgifter eller känsliga data kan visas i previewn.
• Ny applikationskod kan logga data som läses.
• En sårbar preview-URL kan exponera läsresultat.
• Kostsamma queries kan påverka belastningen i produktion.
• Antaganden om schemat kan skilja sig mellan branchen och produktion.

Aktivera preview-deployment endast enligt en granskad policy:

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

Använd previewns isolerade miljö för feature flags och secrets som inte gäller databasen. Ersätt inte den automatiska skrivskyddade autentiseringsuppgiften med produktionsuppgiften som ger skrivrättigheter.

Hur bör privata nätverk övervakas och felsökas?

Börja med topologi och konfiguration i stället för att utgå från ett plattformsfel.

Symptom	Troligt område	Kontrollera
Namnet hittas inte	Fel slug/projekt eller tjänsten har inte deployats på nytt	Tjänstlista och miljövariabelnamn
Anslutningen nekas	Resursen är stoppad eller fel port används	Status och loggar från databas/tjänst
Autentiseringen misslyckas	Fel autentiseringsuppgift	Rotation av secrets och användare
Publikt fungerar, privat fungerar inte	Intern variabel eller anslutning till nätverket	Aktivera nätverket, gör en ny deployment
Previewn kan läsa men inte skriva	Förväntad skrivskyddad policy	Ersätt inte autentiseringsuppgiften
Anrop mellan projekt misslyckas	Förväntad isolering	Använd ett publikt autentiserat API

Inspektera applikationens runtime-loggar:

dockup logs production/api --json

Inspektera databasens storlek och applikationens anslutningsfel:

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

Skriv inte ut fullständiga interna anslutnings-URL:er i incidentanteckningar. De kan innehålla autentiseringsuppgifter även om själva värdnamnet inte är hemligt.

Plan för migrering och rollback

Behåll den publika listen­ern under den första fasen. Om deploymenten via den interna vägen misslyckas återställer du applikationens tidigare konfiguration och gör en ny deployment. Gör databasen enbart privat först när den interna vägen har varit stabil.

Så här inaktiverar du hela projektnätverket:

dockup network disable production --json

Detta ska vara en avsiktlig rollback, inte det första felsökningssteget. När nätverket inaktiveras påverkas alla anslutna resurser i projektet.

Logga nätverksändringar via auditloggen:

dockup audit --writes --json

Checklista för privata nätverk i produktion

En komplett runbook för privata nätverk innehåller projektets slug, tjänste- och databassluggar, interna värdnamn, namn på injicerade variabler, policy för publika listeners, policy för preview-åtkomst, backupstatus, ordning för redeployment och rollback-väg.

CPU, RAM och disk är fortfarande usage-based och mäts per minut; privat routing är ett arkitekturval, inte en fast instansklass. Använd PaaS-prissättning förklarad för kostnadsmodellering.

Dockup CLI-referensen innehåller aktuella nätverks- och databaskommandon. För generell isolering av deploymenter, se säkerhetsrutiner.

Modellera auktorisering av tjänster separat från nåbarhet

Ett internt värdnamn bevisar bara att anroparen finns på projektnätverket. Det bevisar inte vilken tjänst som gjorde anropet eller om tjänsten får utföra åtgärden. Behåll applikationsautentisering för känsliga interna API:er och databasautentiseringsuppgifter för dataåtkomst.

Använd tjänstespecifika secrets i stället för en gemensam intern token. Om en preview får skrivskyddad databasåtkomst ska den inte samtidigt få en produktionstoken som kan utlösa skrivningar via ett API.

Mät effekten av övergången

Jämför anslutningslatens, felfrekvens och svarstid vid p95 före och efter bytet till interna slutpunkter. Det primära målet är isolering och en stabil privat väg; eventuell latensförbättring ska mätas och inte utlovas.

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

Spara observationsfönstret och deployment-ID:t. Då får ändringen av privata nätverk ett mätbart klart-kriterium i stället för att avslutas vid ”DNS kunde slås upp”.

Dokumentera undantag från den publika vägen

Vissa externa integrationer, operatörsverktyg eller tjänster i andra projekt kan fortfarande kräva en publik slutpunkt. Lista varje undantag, dess autentisering, ägare och villkor för borttagning. Då förhindrar du att den publika listen­ern förblir aktiv på obestämd tid eftersom ingen minns varför den finns.

En komplett utrullning av privata nätverk kan vara partiell, men varje publik väg ska vara avsiktlig.

Granska interna beroenden efter namnändringar

Ett namnbyte eller en ersättning av en resurs kan ändra den slug som används för .internal-adressering. Inventera konsumenterna innan du ändrar namn, gör en ny deployment av dem med uppdaterade injicerade variabler och verifiera varje privat anslutning.

Det håller privata nätverk stabila medan projektet utvecklas.

Börja med en verifierbar deployment

Aktivera nätverk i ett projekt som inte är produktion, migrera ett beroende till dess .internal-slutpunkt och bevisa rollback-vägen innan du tar bort någon publik listener.

Starta gratis på app.dockup.ai. Free-planen kostar 0 USD per månad, inkluderar 10 USD i startkredit och stöder en workspace, tre databaser och tre deploymenter.

Vanliga frågor

Vilket värdnamn använder Dockup-resurser i det privata nätverket?

Varje tjänst och hanterad databas i samma projekt kan nås via ett stabilt värdnamn på formen <slug>.internal.

Tar aktivering av privata nätverk bort publik databasåtkomst?

Nej. Nätverket är som standard ett tillägg. Använd det separata databas-kommandot för privata nätverk för att ta bort den publika listen­ern när konsumenterna använder den interna vägen.

Kan olika Dockup-projekt nå varandra privat?

Nej. Varje projekt har ett isolerat nätverk, så kommunikation mellan projekt måste använda ett lämpligt publikt och autentiserat gränssnitt.

Kan en PR-preview skriva till produktionsdatabasen?

I ett projekt med privata nätverk skapar Dockup automatiskt en skrivskyddad databasanvändare för previewn. Den tillåter läsning men förhindrar skrivningar med den autentiseringsuppgiften.

Varför måste tjänster deployas på nytt efter att nätverk har aktiverats?

En ny deployment ger den nya containern de interna anslutningsvariablerna och låter applikationen starta med konfigurationen för den privata slutpunkten.