Codex-deployment: Dockup-workflow fra start til slut

En Codex-deployment bør afsluttes med dokumentation – ikke en antagelse. Den praktiske udfordring er ikke at bede Codex om at køre en deploy-kommando. Det handler om at give agenten en grænseflade, der identificerer det præcise mål, venter på en terminal tilstand, returnerer de faktiske exit-koder og viser fejldetaljer uden en browser.

Dockup er deployment-laget i denne workflow. CLI'et giver Codex struktureret JSON for alle understøttede kommandoer, og den medfølgende skill lærer agenten at autentificere, finde services, deploye, diagnosticere og stoppe før destruktive handlinger.

Hvordan installerer du Codex CLI-skillen?

Installér CLI'et globalt, og kør derefter den enkelte skill-installer. Den skriver den kanoniske skill og linker den til både Claude Code og Codex:

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

Den kanoniske skill ligger i ~/.agents/skills/dockup/ og er symlinket til ~/.codex/skills/. Den leveres sammen med dockup-cli, så en almindelig opdatering ændrer den eksekverbare fil og instruktionerne samtidigt:

dockup update

Denne versionskobling er vigtig i en stor command surface. En agent bør aldrig køre et flag, den husker, bare fordi det optrådte i en gammel prompt. Codex bør bruge den pakkede skill og den aktuelle Dockup CLI-reference som autoritativ kilde til kommandoer.

Se agent skills vs MCP for designovervejelserne bag skills.

Hvordan autentificerer Codex uden en interaktiv terminal?

En sandbox eller et CI-job kan muligvis ikke gennemføre browserbaseret login. Angiv et token i processens miljø:

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

DOCKUP_TOKEN har forrang over den lokale konfigurationsfil. Svaret fra whoami viser, om den aktive credential kom fra miljøet eller konfigurationen. Det hjælper Codex med at diagnosticere det almindelige tilfælde, hvor et forældet lokalt token og et CI-token eksisterer samtidig.

Behandl tokenet som en infrastrukturhemmelighed. Læg det ikke i AGENTS.md, SKILL.md, source control, kommandoeksempler, der committes til repositoryet, eller agentens endelige transskript. I CI skal du bruge platformens krypterede secret store og kun eksponere værdien for deployment-trinnet. Det komplette ikke-interaktive mønster er beskrevet i CI/CD with DOCKUP_TOKEN.

Før du giver Codex skriveadgang, skal du fastlægge agentens tilladelsesramme. Et fornuftigt indledende scope omfatter service discovery, deployment, læsning af logs og statuskontrol. Sletning af databaser, destruktion af services, ændringer af teams og oprydning i konfiguration bør fortsat kræve godkendelse.

Hvordan finder eller opretter Codex den korrekte service?

Gør discovery til den første handling. Bed ikke Codex om at omsætte “Payments API” til et gættet slug:

dockup services --json

Hvert resultat indeholder et præcist target i formen project/service. Codex bør kopiere denne værdi til efterfølgende kommandoer og returnere den i sin opsummering.

Hvis der ikke findes en service, skal du oprette en fra Git:

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

Kommandoen opretter servicen, deployer den, blokerer, indtil deploymenten er afgjort, og skriver et .dockup-link i arbejdsbiblioteket. Der bruges en Dockerfile, hvis den findes; ellers udfører Nixpacks automatisk build-detektion.

Når Codex mister sessionstilstand, eller en workflow køres igen efter en netværksafbrydelse, bør den finde services igen og kontrollere det præcise target, før den ændrer noget. Hvis target allerede findes, skal den fortsætte ud fra status og deploymenthistorikken i stedet for at sende endnu en create-request.

Den komplette repository-first-sekvens findes i Git repository to production.

Hvordan bør Codex forberede konfigurationen før deployment?

Bed Codex om at inspicere den aktuelle servicemetadata, før den ændres:

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

Environment-svaret indeholder keys og isSecret-markeringer, mens secret-værdier forbliver maskeret. Codex kan tilføje almindelige variabler og secrets separat:

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

Læg aldrig en production-secret i dockup.yaml; manifestet er egnet til konfiguration i klartekst, der kan gennemgås, ikke til credentials. Eksisterende secret-variabler overskrives eller fjernes ikke af config-as-code-workflowen.

Konfigurér servicens lytteport og readiness check, når du kender dem:

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

En readiness gate gør produktionsverificeringen meningsfuld. Platformen udfører en blue-green-deployment og dirigerer først trafik, når den nye version opfylder gaten.

Hvordan bekræfter produktionsverificering den terminale tilstand?

For en eksisterende service kan du bruge én kommando:

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

Den eksplicitte timeout svarer til standardværdien på 900 sekunder og gør workflowens intention tydelig. Exit 0 betyder, at deploymenten lykkedes. Et resultat, der ikke er nul, med deploy_failed betyder, at build eller deploy endte i en fejl. deploy_timeout betyder, at operationen stadig ikke var terminal, da ventetiden udløb.

Den korrekte branching-logik for Codex baseres på processens status:

Resultat	Codex-handling
Exit 0, status:"success"	Fortsæt med health-, uptime- og sikkerhedsverificering
deploy_failed	Læs build-logs, og identificér den første fejl, der kan handles på
deploy_timeout	Rapportér usikkerheden; kontrollér status, eller prøv igen med en begrundet timeout
not_logged_in	Stop, og bed om et gyldigt token
needs_confirm	Stop, og bed om menneskelig godkendelse

Efter en vellykket Codex-deployment skal du indsamle observerbar dokumentation:

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

Uptime checks kører hvert minut og inkluderer statistik over svartider, f.eks. p95. Sikkerhedsresultaterne omfatter image-CVE'er og konfigurationskontroller. Disse signaler beviser ikke, at forretningslogikken fungerer korrekt, så Codex bør også køre repositoryets egne smoke tests, når de er tilgængelige.

Hvordan bør Codex diagnosticere og komme sig efter en fejlet release?

Build-fejl og runtime-fejl kræver forskellige logs. Brug det seneste build-output, når deploymenten aldrig nåede frem til en container, der kunne køre:

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

Brug runtime-logs, når imaget blev bygget, men applikationen crasher, binder til den forkerte port eller fejler efter startup:

dockup logs production/payments-api --json

Follow mode er nyttig under et langt build:

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

I JSON-mode er follow-output NDJSON, så Codex kan behandle hver batch, efterhånden som den ankommer. Streamen slutter ved en terminal deployment-status og bevarer den faktiske exit-kode for fejlen.

Recovery begynder med historikken – ikke med et gættet rollback-target:

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

Codex bør identificere en kendt vellykket deployment, angive det valgte ID og bevare dokumentationen for fejlen, før den kører den igen. Den bør aldrig vælge “det andet element” uden at verificere status og tidsstempler.

En nyttig slutrapport har syv felter: target, branch eller commit, deployment-ID, exit-kode, terminal status, production-URL og opfølgende handlinger. Dette format gør hver Codex-deployment mulig at gennemgå for en person eller et senere automationstrin.

Et kompakt verificeringsscript

Dette shell-mønster holder deployment og diagnosticering samlet i ét transparent kontrolflow:

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

Scriptet søger ikke efter en succesbesked. Det stoler på CLI'ets exit-kode, gemmer deployment-JSON'et og fejler det kaldende job, når production ikke nåede frem til succes.

Gør retries synlige i stedet for usynlige

Agentsessioner kan blive afbrudt, efter en operation er startet, men før resultatet når frem til transskriptet. Den næste Codex-kørsel bør ikke blindt gentage enhver mutation. Den bør finde servicen igen, inspicere den seneste deployment og fastslå, om den forrige operation nåede en terminal tilstand.

En Codex-deployment-runbook bør klassificere kommandoer som sikre at gentage, sikre kun efter inspektion eller godkendelseskrævende. Reads er sikre at gentage. Oprettelse af services kræver discovery først. En ny deploy er en ny production-begivenhed og bør registreres som sådan. Pruning og andet destruktivt arbejde bør fortsat være menneskelige beslutninger.

Adskil platformverificering fra applikationsverificering

Dockup kan bevise, at et build blev gennemført, at containeren blev ready, og at probes på minutniveau observerer den offentlige service. Codex bør stadig køre applikationsspecifikke kontroller: et offentligt health-endpoint, et autentificeret testrequest eller en smoke test fra repositoryet, som ikke ændrer kundedata.

Det endelige resultat bør angive begge lag. “Platform deployment lykkedes” og “applikationens smoke test bestod” er forskellige påstande. Når kun den første er tilgængelig, bør Codex sige det i stedet for at samle usikkerheden i et grønt flueben.

Bekræft den installerede command surface før automation

En genanvendelig Codex-opgave bør begynde med at kontrollere dockup skill status --json og åbne den aktuelle CLI-reference, når den afhænger af en mindre velkendt option. Det forhindrer en session i at følge et eksempel, der er skrevet til en anden release.

Kontrollen er især nyttig i ephemeral runners, hvor en ny global npm-installation kan afvige fra en udviklers laptop. Codex kan rapportere skill-statussen, før den udfører den første production write, så deployment-registreringen bliver reproducerbar.

Endelig overdragelse

Bevar dokumentationen.

Hold target synligt

Returnér det præcise service-target i slutrapporten.

Bevar beslutningen om kilde

Registrér, om Dockup brugte repositoryets Dockerfile eller Nixpacks. Denne oplysning hjælper den næste Codex-session med at vælge den korrekte build-log og forhindrer, at en ændring i source-layoutet forveksles med en platformshændelse.

Registrér også, om automatisk deploy ved push er aktiveret. Ellers kan en manuel agent-release og en push-udløst release overlappe og skabe to production-begivenheder ud fra den samme undersøgelse.

Gør workflowen klar til production

Kør den første Codex-deployment mod en disposable service eller en service med lav risiko, og promover derefter den samme verificerede command contract til production.

npm install -g dockup-cli
dockup skill install

Den første kommando installerer CLI'et. Den anden installerer den matchende Dockup-skill til Claude Code og Codex. Kom gratis i gang på app.dockup.ai.

FAQ

Kan Codex deploye et nyt Git-repository med én kommando?

Ja. dockup create kan oprette servicen, deploye den, vente på det terminale resultat og linke det aktuelle bibliotek, når den bruges sammen med --deploy, --wait og --link.

Hvordan bør Codex autentificere til Dockup?

Brug DOCKUP_TOKEN i processens miljø, og verificér det med dockup whoami --json. Det undgår interaktivt browser-login i sandboxes og CI.

Hvad beviser, at en Codex-deployment lykkedes?

Deploy-kommandoen skal afsluttes med exit 0 efter at være kørt med --wait, og dens JSON skal rapportere en vellykket terminal status. Følg op med status, uptime og smoke tests af applikationen.

Kan Codex læse production-secrets fra Dockup?

Nej. Secret-værdier er maskeret i output. Codex kan angive eller erstatte en secret, men modtager ikke den gemte værdi, når konfigurationen listes.

Hvad skal Codex gøre med needs_confirm?

Den skal stoppe og anmode om eksplicit menneskelig godkendelse. Fejlen angiver, at en destruktiv kommando blev forsøgt uden den påkrævede --yes-bekræftelse.