Codex-deployment: Dockup-workflow van begin tot eind

Een Codex-deployment hoort te eindigen met bewijs, niet met een aanname. De praktische uitdaging is niet om Codex te vragen een deployopdracht uit te voeren, maar om de agent een interface te geven die het exacte doel identificeert, wacht op een terminale status, echte exitcodes retourneert en foutdetails beschikbaar maakt zonder browser.

Dockup is de deploymentlaag voor deze workflow. De CLI levert Codex bij elke ondersteunde opdracht gestructureerde JSON, en de meegeleverde skill leert de agent hoe die moet authenticeren, services ontdekken, deployen, problemen diagnosticeren en stoppen vóór destructieve bewerkingen.

Hoe installeer je de Codex CLI-skill?

Installeer de CLI globaal en voer daarna de installer voor de skill uit. Die schrijft de canonieke skill en maakt er links naartoe in zowel Claude Code als Codex:

npm install -g dockup-cli
dockup skill install
dockup skill status --json

De canonieke skill staat in ~/.agents/skills/dockup/ en wordt via een symlink gekoppeld aan ~/.codex/skills/. De skill wordt meegeleverd met dockup-cli, zodat een normale update zowel het uitvoerbare bestand als de bijbehorende instructies aanpast:

dockup update

Deze koppeling tussen versies is belangrijk bij een groot aantal opdrachten. Een agent mag nooit zomaar een onthouden flag uitvoeren omdat die in een oude prompt stond. Codex moet de meegeleverde skill en de actuele Dockup CLI-reference als bron voor zijn opdrachten gebruiken.

Bekijk agent skills vs MCP voor de ontwerpredenen achter skills.

Hoe authenticeert Codex zonder interactieve terminal?

Een sandbox of CI-job kan mogelijk geen browsergebaseerde login voltooien. Stel een token in de procesomgeving in:

export DOCKUP_TOKEN="<TOKEN>"
dockup whoami --json

DOCKUP_TOKEN heeft voorrang op het lokale configuratiebestand. De whoami-response meldt of de actieve credential uit de omgeving of uit de configuratie kwam. Dat helpt Codex bij het diagnosticeren van het veelvoorkomende geval waarin een verouderd lokaal token en een CI-token naast elkaar bestaan.

Behandel het token als een infrastructuurgeheim. Zet het niet in AGENTS.md, SKILL.md, source control, opdrachtvoorbeelden die in de repository worden vastgelegd of het eindtranscript van de agent. Gebruik in CI de versleutelde secret store van het platform en stel de waarde alleen beschikbaar aan de deploymentstap. Het volledige patroon voor non-interactive gebruik staat beschreven in CI/CD met DOCKUP_TOKEN.

Bepaal eerst de permission envelope voordat je Codex schrijftoegang geeft. Een redelijke eerste scope omvat servicediscovery, deployment, het lezen van logs en statuscontroles. Het verwijderen van databases, het vernietigen van services, teamwijzigingen en het opschonen van configuratie horen approval-gated te blijven.

Hoe vindt of maakt Codex de juiste service?

Maak discovery de eerste bewerking. Vraag Codex niet om “Payments API” om te zetten in een geraden slug:

dockup services --json

Elk resultaat bevat een exacte target in de vorm project/service. Codex moet die waarde in volgende opdrachten overnemen en in de samenvatting teruggeven.

Als er geen service bestaat, maak je er een aan vanuit Git:

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

De opdracht maakt de service aan, deployt die, wacht totdat de deployment is afgerond en schrijft een .dockup-link naar de werkdirectory. Als er een Dockerfile aanwezig is, wordt die gebruikt; anders voert Nixpacks automatische build-detectie uit.

Wanneer Codex de sessiestatus kwijtraakt of een workflow na een netwerkonderbreking opnieuw wordt uitgevoerd, moet de agent services opnieuw ontdekken en het exacte doel inspecteren voordat er iets wordt gewijzigd. Als het doel al bestaat, ga dan verder op basis van de status en deploymentgeschiedenis in plaats van nogmaals een create-request uit te voeren.

De volledige repository-first-volgorde staat in Van Git-repository naar productie.

Hoe bereidt Codex de configuratie voor vóór een deployment?

Vraag Codex om de huidige metadata van de service te inspecteren voordat die wordt gewijzigd:

dockup info production/payments-api --json
dockup env list -s production/payments-api --json

De environment-response bevat keys en isSecret-markeringen, terwijl secretwaarden gemaskeerd blijven. Codex kan gewone variabelen en secrets afzonderlijk toevoegen:

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

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

Zet nooit een production secret in dockup.yaml; het manifest is geschikt voor controleerbare configuratie in plain text, niet voor credentials. Bestaande secretvariabelen worden niet overschreven of verwijderd door de config-as-code-workflow.

Configureer de poort waarop de service luistert en de readiness check wanneer die bekend zijn:

dockup set production/payments-api --port 3000 --json
dockup health production/payments-api \
  --path /health \
  --interval 5 \
  --retries 5 \
  --json

Een readiness gate maakt de productieverificatie betekenisvol. Het platform voert een blue-green deployment uit en routeert verkeer pas nadat de nieuwe versie aan de gate voldoet.

Hoe bevestigt productieverificatie de terminale status?

Gebruik voor een bestaande service één opdracht:

dockup deploy production/payments-api \
  --wait \
  --timeout 900 \
  --json

De expliciete timeout komt overeen met de standaardwaarde van 900 seconden en maakt de bedoeling van de workflow zichtbaar. Exit 0 betekent dat de deployment is geslaagd. Een resultaat dat niet nul is en deploy_failed bevat, betekent dat de build of deploy is mislukt. deploy_timeout betekent dat de bewerking nog geen terminale status had toen de wachttijd eindigde.

De juiste branchinglogica voor Codex is gebaseerd op de processtatus:

Resultaat	Actie van Codex
Exit 0, status:"success"	Ga door met health-, uptime- en securityverificatie
deploy_failed	Lees de buildlogs en identificeer de eerste fout waarop actie kan worden ondernomen
deploy_timeout	Rapporteer onzekerheid; inspecteer de status of probeer opnieuw met een gemotiveerde timeout
not_logged_in	Stop en vraag om een geldig token
needs_confirm	Stop en vraag menselijke goedkeuring

Verzamel na een geslaagde Codex-deployment waarneembaar bewijs:

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

Uptime-checks worden elke minuut uitgevoerd en bevatten statistieken over de responstijd, zoals p95. Securityresultaten bevatten image-CVE's en configuratiecontroles. Deze signalen bewijzen niet dat de applicatie functioneel correct is, dus Codex moet ook de eigen smoke tests van de repository uitvoeren wanneer die beschikbaar zijn.

Hoe diagnosticeert Codex een mislukte release en herstelt de agent daarvan?

Buildfouten en runtimefouten vereisen verschillende logs. Gebruik de meest recente buildoutput wanneer de deployment nooit een uitvoerbare container heeft bereikt:

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

Gebruik runtimelogs wanneer de image wel is gebouwd, maar de applicatie crasht, aan de verkeerde poort bindt of na het opstarten faalt:

dockup logs production/payments-api --json

Follow-modus is nuttig tijdens een lange build:

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

In JSON-modus is follow-output NDJSON, zodat Codex elke batch kan verwerken zodra die binnenkomt. De stream eindigt bij een terminale deploymentstatus en behoudt de echte exitcode van de fout.

Herstel begint met de geschiedenis, niet met een gegokt rollbackdoel:

dockup deployments production/payments-api -n 20 --json
dockup rollback <deploymentId> production/payments-api --json

Codex moet een bekende geslaagde deployment identificeren, de geselecteerde ID vermelden en het bewijs van de fout bewaren voordat de agent die opnieuw uitvoert. De agent mag nooit zonder controle van status en timestamps “het tweede item” kiezen.

Een nuttig eindrapport bevat zeven velden: doel, branch of commit, deployment-ID, exitcode, terminale status, productie-URL en vervolgstappen. Met dat format kan elke Codex-deployment door een persoon of een latere automatiseringsstap worden beoordeeld.

Een compact verificatiescript

Dit shellpatroon houdt deployment en diagnose in één transparante control flow:

if dockup deploy production/payments-api --wait --json > deploy-result.json; then
  dockup status production/payments-api --json
  dockup uptime production/payments-api --hours 24 --json
else
  dockup logs production/payments-api --build --json
  exit 1
fi

Het script zoekt niet naar een succeszin met grep. Het vertrouwt op de exitcode van de CLI, bewaart de deployment-JSON en laat de aanroepende job falen wanneer de productie geen succesvolle status heeft bereikt.

Maak retries zichtbaar in plaats van onzichtbaar

Agent-sessies kunnen worden onderbroken nadat een bewerking is gestart, maar voordat het resultaat het transcript bereikt. De volgende Codex-run mag niet blind elke mutatie herhalen. De agent moet de service opnieuw ontdekken, de meest recente deployment inspecteren en vaststellen of de vorige bewerking een terminale status heeft bereikt.

Een Codex-deployment-runbook moet opdrachten indelen als veilig om te herhalen, alleen veilig na inspectie of approval-gated. Reads zijn veilig om te herhalen. Voor het aanmaken van een service is eerst discovery vereist. Een nieuwe deploy is een nieuw productie-event en moet als zodanig worden geregistreerd. Pruning en ander destructief werk blijven menselijke beslissingen.

Scheid platformverificatie van applicatieverificatie

Dockup kan aantonen dat een build is voltooid, dat de container gereed is en dat probes op minuutniveau de publieke service waarnemen. Codex moet nog steeds applicatiespecifieke controles uitvoeren: een publiek health-endpoint, een geauthenticeerd testrequest of een door de repository geleverde smoke test die geen klantgegevens wijzigt.

Het eindresultaat moet beide lagen vermelden. “Platformdeployment geslaagd” en “applicatiesmoke test geslaagd” zijn verschillende claims. Wanneer alleen de eerste beschikbaar is, moet Codex dat zeggen in plaats van onzekerheid samen te vatten in een groen vinkje.

Bevestig de geïnstalleerde commandoset vóór automatisering

Een herbruikbare Codex-taak moet beginnen met het controleren van dockup skill status --json en het openen van de actuele CLI-reference wanneer de taak afhankelijk is van een minder bekende optie. Zo voorkom je dat een sessie een voorbeeld volgt dat voor een andere release is geschreven.

Deze controle is vooral nuttig in ephemeral runners, waar een nieuwe globale npm-installatie kan verschillen van die op de laptop van een ontwikkelaar. Codex kan de status van de skill rapporteren voordat de agent de eerste productie-write uitvoert, waardoor het deploymentrecord reproduceerbaar wordt.

Finale overdracht

Bewaar het bewijs.

Houd het doel zichtbaar

Geef het exacte servicetarget terug in het eindrapport.

Leg de bronkeuze vast

Leg vast of Dockup het Dockerfile van de repository of Nixpacks heeft gebruikt. Dit helpt de volgende Codex-sessie om het juiste buildlog te kiezen en voorkomt dat een wijziging in de bronstructuur wordt aangezien voor een platformincident.

Leg ook vast of automatische deployment bij een push is ingeschakeld. Anders kunnen een handmatige agentrelease en een door een push getriggerde release elkaar overlappen en twee productie-events veroorzaken vanuit hetzelfde onderzoek.

Breng de workflow in productie

Voer de eerste Codex-deployment uit op een disposable service of een service met een laag risico en promoot vervolgens hetzelfde geverifieerde commandocontract naar productie.

npm install -g dockup-cli
dockup skill install

De eerste opdracht installeert de CLI. De tweede installeert de bijbehorende Dockup-skill voor Claude Code en Codex. Start gratis via app.dockup.ai.

FAQ

Kan Codex met één opdracht een nieuwe Git-repository deployen?

Ja. dockup create kan de service aanmaken, die deployen, wachten op het terminale resultaat en de huidige directory koppelen wanneer de opdracht wordt gebruikt met --deploy, --wait en --link.

Hoe moet Codex bij Dockup authenticeren?

Gebruik DOCKUP_TOKEN in de procesomgeving en verifieer het met dockup whoami --json. Zo vermijd je een interactieve browserlogin in sandboxes en CI.

Wat bewijst dat een Codex-deployment is geslaagd?

De deployopdracht moet afsluiten met exit 0 nadat die met --wait is uitgevoerd, en de JSON moet een geslaagde terminale status rapporteren. Voer daarna status-, uptime- en applicatiesmokechecks uit.

Kan Codex production secrets uit Dockup lezen?

Nee. Secretwaarden worden gemaskeerd in de output. Codex kan een secret instellen of vervangen, maar ontvangt de opgeslagen waarde niet bij het opvragen van de configuratie.

Wat moet Codex doen met needs_confirm?

De agent moet stoppen en expliciete menselijke goedkeuring vragen. De fout geeft aan dat er zonder de vereiste bevestiging met --yes een destructieve opdracht is geprobeerd.