Codex-deployment: Dockup-arbetsflöde från början till slut

En Codex-deployment bör avslutas med bevis, inte antaganden. Den praktiska utmaningen är inte att be Codex köra ett deploy-kommando, utan att ge agenten ett gränssnitt som identifierar exakt mål, väntar på ett terminaltillstånd, returnerar riktiga exit-koder och visar feldetaljer utan en webbläsare.

Dockup är deploymentlagret för detta arbetsflöde. CLI:t ger Codex strukturerad JSON för varje kommando som stöds, och den medföljande skillen lär agenten att autentisera, hitta tjänster, deploya, felsöka och stanna före destruktiva åtgärder.

Hur installerar du Codex CLI-skillen?

Installera CLI:t globalt och kör sedan den enda skill-installationen. Den skriver den kanoniska skillen och länkar den till både Claude Code och Codex:

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

Den kanoniska skillen finns i ~/.agents/skills/dockup/ och symlänkas till ~/.codex/skills/. Den levereras med dockup-cli, så en vanlig uppdatering ändrar det körbara programmet och instruktionerna tillsammans:

dockup update

Den här versionskopplingen är viktig när kommandoytan är stor. En agent ska aldrig köra en flagga den minns bara för att den förekom i en gammal prompt. Codex ska använda den paketerade skillen och den aktuella Dockup CLI-referensen som auktoritativa källor för kommandon.

Se agent skills vs MCP för bakgrunden till designen av skills.

Hur autentiserar Codex utan en interaktiv terminal?

En sandbox eller ett CI-jobb kanske inte kan slutföra en webbläsarbaserad inloggning. Ange en token i processmiljön:

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

DOCKUP_TOKEN har företräde framför den lokala konfigurationsfilen. Svaret från whoami visar om den aktiva autentiseringsuppgiften kom från miljön eller konfigurationen, vilket hjälper Codex att felsöka det vanliga fallet där en gammal lokal token och en CI-token finns samtidigt.

Behandla token som en infrastrukturhemlighet. Lägg den inte i AGENTS.md, SKILL.md, versionshantering, kommandoexempel som checkas in i repot eller agentens slutliga transkript. I CI använder du plattformens krypterade secret store och exponerar värdet endast för deployment-steget. Det fullständiga icke-interaktiva mönstret beskrivs i CI/CD with DOCKUP_TOKEN.

Bestäm agentens behörighetsram innan du ger Codex skrivåtkomst. Ett rimligt första omfång omfattar tjänsteupptäckt, deployment, loggläsning och statuskontroller. Databasborttagning, destruktion av tjänster, teamändringar och rensning av konfiguration bör fortsatt kräva godkännande.

Hur hittar eller skapar Codex rätt tjänst?

Gör upptäckt till den första åtgärden. Be inte Codex omvandla ”Payments API” till en gissad slug:

dockup services --json

Varje resultat innehåller ett exakt target i formatet project/service. Codex ska kopiera värdet till efterföljande kommandon och returnera det i sin sammanfattning.

När ingen tjänst finns skapar du en från Git:

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

Kommandot skapar tjänsten, deployar den, blockerar tills deploymenten har lösts och skriver en .dockup-länk i arbetskatalogen. En Dockerfile används om den finns; annars utför Nixpacks automatisk build-detektering.

När Codex förlorar sessionsstatus eller ett arbetsflöde körs igen efter ett nätverksavbrott ska agenten upptäcka tjänster på nytt och kontrollera det exakta målet innan något ändras. Om målet redan finns fortsätter den utifrån dess status och deploymenthistorik i stället för att skicka ytterligare en create-begäran.

Den fullständiga repository-first-sekvensen finns i Git repository to production.

Hur bör Codex förbereda konfigurationen före deployment?

Be Codex inspektera aktuell metadata för tjänsten innan den ändras:

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

Miljös svaret innehåller nycklar och isSecret-markeringar, medan hemliga värden förblir maskerade. Codex kan lägga till vanliga variabler och hemligheter 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ägg aldrig en produktionshemlighet i dockup.yaml; manifestet lämpar sig för granskningsbar vanlig konfiguration, inte autentiseringsuppgifter. Befintliga hemliga variabler skrivs inte över eller rensas bort av config-as-code-arbetsflödet.

Konfigurera tjänstens lyssningsport och readiness check när de är kända:

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 produktionsverifieringen meningsfull. Plattformen utför en blue-green-deployment och dirigerar trafik först när den nya versionen uppfyller gaten.

Hur bekräftar produktionsverifieringen terminaltillståndet?

För en befintlig tjänst använder du ett kommando:

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

Den explicita timeouten motsvarar standardvärdet på 900 sekunder och gör avsikten med arbetsflödet tydlig. Exit 0 betyder att deploymenten lyckades. Ett resultat som inte är noll och innehåller deploy_failed betyder att builden eller deploymenten misslyckades. deploy_timeout betyder att åtgärden fortfarande inte hade nått ett terminaltillstånd när väntetiden löpte ut.

Codex korrekta förgreningslogik baseras på processstatusen:

Resultat	Codex-åtgärd
Exit 0, status:"success"	Fortsätt med verifiering av health, uptime och security
deploy_failed	Läs buildloggarna och identifiera det första åtgärdbara felet
deploy_timeout	Rapportera osäkerhet; kontrollera status eller försök igen med en motiverad timeout
not_logged_in	Stoppa och begär en giltig token
needs_confirm	Stoppa och be om mänskligt godkännande

Efter en lyckad Codex-deployment samlar du in observerbara bevis:

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

Uptime-kontroller körs varje minut och innehåller statistik över svarstider, till exempel p95. Security-resultat innehåller CVE:er i images och konfigurationskontroller. Dessa signaler bevisar inte att verksamheten fungerar korrekt, så Codex bör också köra repots egna smoke tests när sådana finns.

Hur bör Codex felsöka och återställa efter en misslyckad release?

Buildfel och runtime-fel kräver olika loggar. Använd den senaste build-outputen när deploymenten aldrig nådde en körbar container:

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

Använd runtime-loggar när imagen byggdes men applikationen kraschar, binder till fel port eller misslyckas efter startup:

dockup logs production/payments-api --json

Follow-läge är användbart under en lång build:

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

I JSON-läge är follow-outputen NDJSON, vilket gör att Codex kan bearbeta varje batch när den anländer. Strömmen avslutas vid ett terminalt deploymenttillstånd och bevarar den riktiga felkoden från processen.

Återställning börjar med historiken, inte med ett gissat rollback-mål:

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

Codex ska identifiera en känd lyckad deployment, ange det valda ID:t och bevara felbevisen innan den kör om den. Den ska aldrig välja ”det andra objektet” utan att verifiera status och tidsstämplar.

En användbar slutrapport har sju fält: mål, branch eller commit, deployment-ID, exit-kod, terminal status, produktions-URL och uppföljande åtgärder. Det formatet gör varje Codex-deployment granskningsbar för en person eller ett senare automatiseringssteg.

Ett kompakt verifieringsskript

Det här shell-mönstret håller deployment och felsökning i samma transparenta kontrollflöde:

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

Skriptet letar inte efter en lyckad formulering. Det litar på CLI:ts exit-kod, sparar deploymentens JSON och får det anropande jobbet att misslyckas när produktionen inte nådde ett lyckat resultat.

Gör omkörningar observerbara i stället för osynliga

Agentsessioner kan avbrytas efter att en åtgärd har startat men innan resultatet når transkriptet. Nästa Codex-körning ska därför inte blint upprepa varje ändring. Den ska upptäcka tjänsten på nytt, kontrollera den senaste deploymenten och fastställa om den föregående åtgärden nådde ett terminaltillstånd.

En Codex-deployment-runbook bör klassificera kommandon som säkra att upprepa, säkra först efter inspektion eller sådana som kräver godkännande. Läsningar är säkra att upprepa. Tjänsteskapande kräver upptäckt först. En ny deploy är en ny produktionshändelse och bör dokumenteras som sådan. Rensning och annat destruktivt arbete förblir mänskliga beslut.

Separera plattformsverifiering från applikationsverifiering

Dockup kan bevisa att en build slutfördes, att containern blev redo och att kontroller på minutnivå observerar den publika tjänsten. Codex bör fortfarande köra applikationsspecifika kontroller: en publik health-endpoint, en autentiserad testbegäran eller ett smoke test från repot som inte ändrar kunddata.

Slutresultatet bör ange båda lagren. ”Platform deployment succeeded” och ”application smoke test passed” är olika påståenden. När bara det första är tillgängligt bör Codex säga det i stället för att komprimera osäkerheten till en grön bock.

Bekräfta den installerade kommandoytan före automatisering

En återanvändbar Codex-uppgift bör börja med att kontrollera dockup skill status --json och öppna den aktuella CLI-referensen när den är beroende av ett mindre välbekant alternativ. Det förhindrar att en session följer ett exempel som skrevs för en annan release.

Kontrollen är särskilt användbar i temporära runners där en ny global npm-installation kan skilja sig från den på en utvecklares laptop. Codex kan rapportera skillens status innan den utför den första skrivningen i produktion, vilket gör deployment-posten reproducerbar.

Slutlig överlämning

Bevara bevisen.

Håll målet synligt

Returnera tjänstens exakta mål i slutrapporten.

Bevara källbeslutet

Dokumentera om Dockup använde repots Dockerfile eller Nixpacks. Den här informationen hjälper nästa Codex-session att välja rätt buildlogg och förhindrar att en förändring i källkodens struktur misstas för en plattformsincident.

Dokumentera också om automatisk deployment vid push är aktiverad. Annars kan en manuell agentrelease och en push-utlöst release överlappa och skapa två produktionshändelser från samma utredning.

Sätt arbetsflödet i produktion

Kör den första Codex-deploymenten mot en engångstjänst eller en tjänst med låg risk och befordra sedan samma verifierade kommandokontrakt till produktion.

npm install -g dockup-cli
dockup skill install

Det första kommandot installerar CLI:t. Det andra installerar den matchande Dockup-skillen för Claude Code och Codex. Kom igång kostnadsfritt på app.dockup.ai.

Vanliga frågor

Kan Codex deploya ett nytt Git-repository med ett enda kommando?

Ja. dockup create kan skapa tjänsten, deploya den, vänta på terminalresultatet och länka den aktuella katalogen när det används med --deploy, --wait och --link.

Hur bör Codex autentisera mot Dockup?

Använd DOCKUP_TOKEN i processmiljön och verifiera den med dockup whoami --json. Det undviker interaktiv webbläsarinloggning i sandboxes och CI.

Vad bevisar att en Codex-deployment lyckades?

Deploy-kommandot måste avslutas med 0 efter att ha körts med --wait, och dess JSON måste rapportera ett lyckat terminaltillstånd. Följ upp med status, uptime och applikationens smoke tests.

Kan Codex läsa produktionshemligheter från Dockup?

Nej. Hemliga värden är maskerade i outputen. Codex kan ange eller ersätta en hemlighet, men får inte det lagrade värdet när konfigurationen listas.

Vad bör Codex göra med needs_confirm?

Den ska stoppa och begära uttryckligt mänskligt godkännande. Felet visar att ett destruktivt kommando försöktes köras utan den obligatoriska --yes-bekräftelsen.