Van Git-repository naar productie: Dockup-deploymenthandleiding

Een Git-repository naar productie brengen vereist meer dan een remote koppelen en op deploy drukken. Het platform moet weten op welke service moet worden gericht, welke branch moet worden gebruikt, wat de buildmethode en het startcommando zijn, op welke poort de applicatie luistert, welke environment wordt gebruikt, welke health gate geldt en hoe herstel moet verlopen. Dockup maakt die beslissingen expliciet en ondersteunt zowel automatische Nixpacks-builds als Dockerfiles die door de repository worden beheerd.

Deze handleiding begint met een repository die nog nooit is gedeployed en eindigt met een geverifieerde URL, deploymentgeschiedenis, logs en een getest rollback-commando.

Wat moet je controleren vóór de eerste production deploy?

Controleer of de repository deploybaar is zonder niet-gedocumenteerde lokale state. Een schone clone moet alles bevatten wat nodig is om dependencies te installeren en de applicatie te starten, met uitzondering van secrets.

Gebruik deze checklist:

Controle	Verwacht resultaat
Default branch	De bedoelde production branch bestaat
Dependency lockfile	Gecommit voor reproduceerbare installs
Startproces	Bindt aan de geconfigureerde poort en 0.0.0.0
Health-route	Geeft succes terug zonder externe side effects
Databasemigraties	Hebben een expliciet en veilig uitvoeringsplan
Secrets	Worden buiten Git opgeslagen
Persistente bestanden	Gebruiken een volume, niet het containerbestandssysteem
Rollback	De vorige deployment kan opnieuw worden uitgevoerd

Installeer de CLI en authenticeer:

npm install -g dockup-cli
export DOCKUP_TOKEN="<TOKEN>"
dockup whoami --json

Bekijk bestaande services voordat je iets aanmaakt:

dockup services --json

Zo voorkom je dubbele resources en bevestig je de exacte conventie voor workspace en target.

Hoe ondersteunt Dockup create Git-deployment?

Met het gebruikelijke commando voor de eerste deployment maak je de service aan, deploy je deze, wacht je op het resultaat en koppel je de huidige directory:

dockup create api \
  --repo https://github.com/acme/api \
  --project production \
  --branch main \
  --deploy \
  --wait \
  --link \
  --json

Het resulterende target is production/api. De .dockup-link zorgt ervoor dat latere commando’s deze service kunnen vinden wanneer ze vanuit de repository worden uitgevoerd, maar in productiondocumentatie moet je altijd het volledige target vastleggen.

Na een onderbroken provisioningpoging vermeld je de services en controleer je het exacte target voordat je opnieuw een create uitvoert:

dockup services --json

Als production/api al bestaat, ga je verder door de status en deploymentgeschiedenis te bekijken. Zo voorkom je dat een onduidelijk netwerkresultaat leidt tot een dubbele service. Bewaar toegangsgegevens voor de repository buiten source control en commandoutput.

Hoe kiest Dockup tussen Nixpacks en Dockerfile?

Als de repository een Dockerfile bevat, gebruikt Dockup die. Anders detecteert Nixpacks de applicatie en bouwt deze automatisch. Door die volgorde is de expliciete containerdefinitie in de repository leidend.

Nixpacks is een goede eerste keuze wanneer de applicatie de gebruikelijke conventies van het ecosysteem volgt en geen aanpassingen op besturingssysteemniveau nodig heeft. Een Dockerfile is nuttig wanneer je een specifieke base image, systeempakketten, een multi-stage build, een aangepaste runtime user of exacte copy boundaries nodig hebt.

Je hoeft geen leeg Dockerfile toe te voegen om er alleen maar “production ready” uit te zien. Een onjuist Dockerfile kan minder reproduceerbaar zijn dan een conventionele automatische build. Gebruik het beslisproces in Nixpacks vs Dockerfile.

Inspecteer de service nadat je deze hebt aangemaakt:

dockup info production/api --json

De response bevat de repository-URL, branch, deploymenttype, poort, build- en startinstellingen, environment keys, custom domains en gegevens over de laatste deployment.

Als de gedetecteerde commando’s een override nodig hebben, gebruik je de gedocumenteerde instellingen:

dockup set production/api \
  --build "npm ci && npm run build" \
  --start "npm start" \
  --port 3000 \
  --json

De instellingen worden toegepast bij de volgende deployment.

Hoe configureer je de production environment en health?

Voeg gewone waarden en secrets afzonderlijk toe:

dockup env set NODE_ENV=production \
  -s production/api \
  --json

dockup env set DATABASE_URL="$DATABASE_URL" \
  --secret \
  -s production/api \
  --json

Secretwaarden worden gemaskeerd wanneer je de environment opvraagt. Je kunt ze instellen of vervangen, maar de opgeslagen waarde wordt niet teruggegeven.

Wijzigingen in de environment vereisen een redeploy, omdat het draaiende proces niet achteraf een nieuwe environment kan ontvangen. De volledige lifecycle wordt uitgelegd in environment variables and secrets.

Configureer een health gate die readiness weergeeft:

dockup health production/api \
  --path /healthz \
  --interval 5 \
  --timeout 3 \
  --retries 5 \
  --json

Dockup gebruikt een zero-downtime blue-green flow en stuurt pas verkeer naar de nieuwe deployment nadat readiness is geslaagd. Als er geen HTTP-pad is geconfigureerd, kan de gate terugvallen op readiness van de TCP-poort.

Een health-route moet controleren of het applicatieproces klaar is om requests te verwerken. Voorkom dat de route destructieve controles of dure full-systemtests uitvoert. Diepe dependencychecks kunnen valse storingen veroorzaken wanneer een optionele service degraded is.

Hoe deploy, monitor en verifieer je productie?

Start de release en wacht op een terminale status:

dockup deploy production/api --wait --json

De standaardtimeout is 900 seconden. Exit 0 betekent succes. deploy_failed en deploy_timeout leveren een non-zero resultaat op, zodat shellscripts en CI-systemen correct stoppen.

Bekijk de build als NDJSON:

dockup logs production/api --build -f --json

De stream eindigt bij succes of een fout. Als de build slaagt maar de container crasht, bekijk je de runtime logs:

dockup logs production/api --json

Controleer na een geslaagde release de platformstatus en het publieke gedrag:

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

Uptime-probes worden elke minuut uitgevoerd en rapporteren de gemiddelde responstijd en de p95-responstijd. Security scanning controleert image-CVE’s en configuratie. Voeg een applicatiespecifieke smoke test toe voor het daadwerkelijke business-endpoint; platform-readiness is noodzakelijk, maar niet voldoende.

De uitgebreide methode voor logs vind je in build- en runtime-logdebugging.

Hoe introduceer je automatische deployments en previews?

Voer de eerste productierelease handmatig uit, zodat je elke grens voldoende kunt observeren. Zodra de build, health gate en rollbackroute bekend zijn, schakel je deployment bij een push in:

dockup auto-deploy production/api --on --json

Automatische deployment moet een protected branch en code-reviewbeleid volgen. Een push is een productiontrigger, dus repositoryrechten worden infrastructuurrechten.

Pull request- en branch-previews bieden geïsoleerde URL’s en environments:

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

In een project met private networking maken previews deel uit van het projectnetwerk. Ze kunnen dezelfde productiondatabase bereiken via <slug>.internal, maar Dockup maakt automatisch een read-only database user voor de preview aan. De preview kan data in productionvorm inzien zonder ernaar te schrijven.

Dit neemt privacyverplichtingen niet weg. Previewtoegang moet nog steeds worden beperkt en geaudit, en mag alleen worden gebruikt wanneer het is toegestaan om productiondata te lezen.

Hoe voer je een rollback uit na een slechte deployment?

Bewaar bewijs voordat je met herstel begint. Lees buildlogs bij een buildfout en runtime logs bij een crash. Bekijk daarna de deploymentgeschiedenis:

dockup deployments production/api -n 20 --json

Selecteer een deployment-ID waarvan de status en timestamp bekend zijn en voer deze opnieuw uit:

dockup rollback <deploymentId> production/api --json

Een rollback moet een expliciete incidentactie zijn. Leg de ID van de mislukte deployment, de gekozen recovery-ID, de reden en de vervolgreparatie vast. Als een databasemigratie niet backward-compatible is, herstelt een rollback van alleen de applicatie mogelijk niet de compatibiliteit; het ontwerp van de migratie moet onderdeel zijn van het releaseplan.

De handleiding voor zero-downtime deployment legt de verkeersomschakeling uit. De Dockup CLI reference documenteert alle commandoflags.

Registratie van de afgeronde eerste deployment

Leg aan het einde van de workflow van Git-repository naar productie het volgende vast:

• Exact project/service-target.
• Repository en production branch.
• Buildmethode: Nixpacks of Dockerfile.
• Build- en startcommando’s wanneer deze zijn overschreven.
• Luisterende poort en health-pad.
• Deployment-ID en terminale status.
• Production-URL en plan voor custom domains.
• Uptime- en securityverificatie.
• Rollback-deployment-ID of selectieregel.

Met deze registratie wordt de tweede deployment een routinehandeling in plaats van opnieuw een ontdekkingsproces.

Houd applicatiestate gescheiden van de container image

Het beschrijfbare bestandssysteem binnen een servicecontainer moet als vervangbaar worden beschouwd. Een nieuwe deployment maakt een nieuwe versie aan en een rollback voert een oudere image opnieuw uit; bestanden die alleen in de oude container zijn geschreven, vormen geen duurzame datastrategie.

Gebruik managed databases voor relationele data, documentdata of cachestate en koppel een volume voor bestanden die tussen deployments moeten blijven bestaan. Controleer de mountpaden vóór de eerste productierelease. Een directory voor containerized uploads die nooit is gemount, kan gezond lijken totdat de volgende deploy de data verwijdert.

Bekijk persistente volumes en snapshots voordat je user-generated files verplaatst. Gebruik voor databasestate het back-upsysteem van de betreffende database in plaats van een hot volume snapshot te beschouwen als een transaction-consistente back-up.

Schat de eerste maand zonder een vaste instancefactuur te verzinnen

Dockup meet CPU-, RAM- en diskgebruik per minuut en trekt het verbruik af van het plansaldo. Het Free-plan bevat $10 starttegoed en maximaal drie deployments; het aanbevolen Pro-plan kost $20 per maand en bevat $20 gebruikstegoed.

Bekijk het CPU-, RAM- en diskgebruik van de service in app.dockup.ai zodra de service daadwerkelijk verkeer verwerkt. Gebruik het gemeten verbruik per minuut — niet een geschat maximum — om te bepalen of de service, database of persistente disk moet worden aangepast.

Controleer een schone tweede deployment

Breng na de eerste release een onschadelijke, gereviewde wijziging aan en deploy opnieuw. Zo bevestig je dat de repositorylink, aannames over de buildcache, health gate, environment en geschiedenis als doorlopend proces werken en niet alleen bij een eenmalig geslaagde provisioning.

Houd het target expliciet

Leg de uiteindelijke project/service-tekenreeks vast.

Bewaar de release-URL

Leg de production-URL naast de deployment-ID vast.

Bevestig de volgende trigger

Leg vast of toekomstige releases handmatig gebeuren of gebruikmaken van optionele deployment bij een push. Zo blijven repositoryrechten, branch protection en productionverwachtingen ook na de eerste deployment op elkaar afgestemd.

Begin met een verifieerbare deployment

Kies een kleine repository met een duidelijk startcommando en een health-route en leg na de eerste geslaagde release het exacte target en de rollback-ID vast.

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

FAQ

Kan Dockup een repository zonder Dockerfile deployen?

Ja. Als er geen Dockerfile aanwezig is, gebruikt Dockup Nixpacks om de applicatie automatisch te detecteren en te bouwen.

Wat doet dockup create --link?

Het schrijft een .dockup-link naar de huidige directory, zodat latere commando’s het bijbehorende project/service-target kunnen vinden.

Waarom moet je de eerste deploy met --wait uitvoeren?

Het commando blijft gekoppeld totdat de deployment succes, een fout of een timeout bereikt en retourneert een exitcode die het terminale resultaat correct weergeeft.

Worden wijzigingen in environmentvariabelen onmiddellijk toegepast?

Nee. Ze worden toegepast op een nieuwe container bij de volgende deployment. Redeploy de service daarom nadat je de environmentconfiguratie hebt gewijzigd.

Hoe voert Dockup een rollback van een applicatie uit?

Bekijk de deploymentgeschiedenis, identificeer een bekende eerdere deployment-ID en gebruik dockup rollback met die ID en het exacte servicetarget.