JournalindeksDockup / feltnote
Note / claude-code-production-deployment

Claude Code-deployment: Produktionsguide

Claude Code-deployment med Dockup: installer agentens skill, godkend sikkert, deploy fra Git, verificer resultatet, og håndtér produktion sikkert.

Claude Code-deployment bliver først pålideligt, når agenten kan skelne mellem “anmodning accepteret” og “produktionen er sund.” Dockup leverer dette deploymentlag gennem en CLI, der er designet til maskinkaldere: struktureret JSON, reelle process exit codes og en --wait-tilstand, der forbliver tilknyttet, indtil et deployment når en terminal tilstand.

Denne guide fører et repository fra lokalt arbejde til en verificeret produktionsrelease. Den definerer også, hvilke tilladelser Claude Code bør få, hvilken dokumentation den skal returnere, og hvornår et menneske skal godkende en destruktiv handling.

Hvad kræver Claude Code-deployment før produktion?

En coding agent bør ikke begynde med at gætte et servicenavn eller klikke sig gennem et dashboard. Giv den i stedet en afgrænset arbejdsaftale: find det præcise mål, udfør én tilsigtet ændring, vent på resultatet, og rapportér maskinlæsbar dokumentation.

De grundlæggende forudsætninger er enkle:

KravHvorfor det er vigtigtVerificering
Node.js 18 eller nyereKræves af Dockup CLI-pakkennode --version
Dockup-kontoEjer workspaces, services og databasesLog ind på app.dockup.ai
Git-repositoryKilde til service-buildetBekræft remote-URL og branch
API-tokenInteraktiv godkendelsedockup whoami --json
Health-endpoint eller lyttende portStyrer blue-green cutoverdockup health ... --json

Fastlæg produktionsgrænsen, før agenten handler. Claude Code må oprette en service, angive ikke-hemmelig konfiguration, starte et deployment, inspicere logs og foreslå en rollback. Den bør ikke slette en service, fjerne en database eller rydde op i konfiguration uden udtrykkelig godkendelse fra et menneske.

Dockup understøtter denne grænse. Destruktive kommandoer nægter at fortsætte uden --yes og returnerer en struktureret needs_confirm-fejl i stedet for at betragte manglende bekræftelse som en invitation til at improvisere. Se produktionsværn for AI-agenter for en bredere politik.

Hvordan installerer man Claude Code-skillen og godkender sikkert?

Installer CLI'en, installér den medfølgende skill, og verificér, at skillen matcher den installerede binær:

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

Installationsprogrammet skriver den kanoniske skill til ~/.agents/skills/dockup/ og linker den til Claude Codes skill-mappe. Da skillen leveres i den samme npm-pakke som CLI'en, opdaterer dockup update begge dele. Claude Code behøver ikke stole på en kopieret kommandoreference, der muligvis beskriver flags, som den lokale binær ikke understøtter.

Brug et environment-token til autonome sessioner:

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

Et vellykket svar identificerer kontoen og angiver tokenSource som env. Indsæt ikke tokenet i en prompt, commit det ikke til repositoryet, og skriv det ikke ud i en CI-log. Secret-værdier, der er gemt i Dockup, maskeres, når konfigurationen læses igen.

Den komplette Dockup CLI-reference er den autoritative kommandoflade. Med 135 kommandoer bør Claude Code slå op i den aktuelle reference og den pakkede skill i stedet for at stole på huskede flags.

Da skillen leveres i CLI-pakken, opdaterer dockup update både den eksekverbare fil og instruktionerne. Denne versionsjustering er sikrere end at kopiere en kommandoliste ind i en langlivet prompt.

Hvordan opretter Dockup CLI en service fra Git?

Bed først agenten om at identificere workspacet, og undgå at konstruere slugs ud fra visningsnavne. Eksisterende mål returneres af:

dockup services --json

For et repository, der aldrig har været deployed, kan én transaktion oprette servicen, deploye den, vente på færdiggørelse og linke den aktuelle mappe:

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

Når repositoryet indeholder en Dockerfile, bruger Dockup den. Uden en Dockerfile falder Dockup tilbage til Nixpacks for automatisk build-detektion. Valget forklares i Nixpacks vs Dockerfile, herunder hvornår eksplicitte build-instruktioner er vedligeholdelsesomkostningerne værd.

Kør dockup services --json igen, og inspicér det præcise mål, før du prøver at oprette servicen igen efter en afbrudt session. Hvis servicen allerede findes, skal du fortsætte ud fra dens status i stedet for at sende endnu en create-anmodning.

Når repositoryet er linket, kan kommandoer i det pågældende repository finde målet via .dockup, men produktionsrunbooks bør stadig registrere den fulde project/service-værdi. Discovery er den sikre grænse mellem en usikker tidligere handling og en ny produktionsændring.

Hvordan forbereder man environment variables, databases og health checks?

Hold almindelig konfiguration adskilt fra secrets. Claude Code kan angive en offentlig runtime-værdi og en maskeret secret uden senere at udskrive gemte secret-værdier:

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

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

Environment-ændringer træder i kraft ved det næste deployment. Det er tilsigtet: En kørende container beholder sit aktuelle process environment, indtil den udskiftes. Det komplette driftsmønster er beskrevet i environment variables og secrets.

Hvis applikationen har brug for en managed PostgreSQL-database, skal du oprette den i det valgte workspace og hente dens detaljer via de dokumenterede databasekommandoer:

dockup db create --name main-db --type postgresql --json
dockup db list --json

Private networking kan senere give services og databases stabile <slug>.internal-hostnames i ét project. Lad ikke agenten opfinde en database-URL; brug forbindelsesoplysningerne fra Dockup, og gem dem som en secret.

Konfigurér en readiness gate før den første vigtige produktionsrelease:

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

Dockup udfører zero-downtime blue-green deployment og sender først trafik til den nye version, når health gaten er bestået. Arkitekturen gennemgås i zero-downtime deployments.

Hvordan deployer Claude Code og dokumenterer, at det lykkedes?

Brug --wait; lad ikke agenten fortolke “deployment queued” som “applikationen kører”:

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

Standard-timeout for ventetilstanden er 900 sekunder. Ved succes afslutter kommandoen med 0 og returnerer terminal status, varighed, deployment-ID og URL. Hvis buildet fejler, afslutter den med en non-zero-værdi og code:"deploy_failed". Hvis operationen stadig kører ved timeout, afslutter den med en non-zero-værdi og code:"deploy_timeout".

En nyttig Claude Code-instruktion er: “Betragt process exit code som det primære resultat, og opsummér derefter JSON-felterne.” Det forhindrer optimistiske formuleringer, når platformen allerede har returneret en fejl.

Indsaml tre uafhængige signaler efter succes:

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

status bekræfter servicen og status for det seneste deployment. uptime returnerer overvågningsstatistik minut for minut, herunder den gennemsnitlige svartid og p95. security viser den seneste CVE- og konfigurationsscanning af imaget. Disse checks supplerer sikkerhedspraksisser på applikationsniveau; de erstatter ikke applikationstests.

Hvad skal Claude Code gøre, når produktionen fejler?

Adskil build-fejl fra runtime-fejl. Et fejlslagent build kræver den seneste build-log:

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

En container, der blev buildet, men crasher efter opstart, kræver runtime-output:

dockup logs production/my-api --json

Brug NDJSON follow mode til at overvåge et build, mens du bevarer maskinlæsbare batches:

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

Kommandoen stopper, når deploymentet når en terminal tilstand, og afslutter med en non-zero-værdi, hvis det fejlede. Claude Code kan streame fremdriften uden at opfinde en polling-loop.

Hvis den aktuelle release er usund, og et kendt tidligere deployment skal køres igen, skal du vise historikken og bruge det præcise ID:

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

Agenten bør rapportere, hvilket deployment-ID den valgte, og hvorfor. Rollback er en driftsbeslutning, ikke en erstatning for at forstå fejlen. Bevar build-log, runtime-log, exit code og audit record, så hændelsen fortsat kan rekonstrueres.

En færdig Claude Code-deploymentrapport bør indeholde mål, commit eller branch, deployment-ID, terminal status, URL, forløbet tid, health-resultat og eventuelle opfølgende risici. Denne dokumentation gør en autonom handling til en produktionsændring, der kan gennemgås.

Definér en completion contract for produktion

Indsæt den forventede completion contract i opgaven, før du starter. En nyttig anmodning er: deploy det linkede repository til production/my-api; vent på et terminalt resultat; slet, ryd op i eller overfør ikke noget; returnér fejlkoden og de sidste 60 relevante linjer fra build-loggen ved fejl; returnér ved succes status, URL, deployment-ID, varighed og health-dokumentation.

Denne formulering giver Claude Code et afgrænset mål og et rapporteringsskema. Den forhindrer også agenten i “hjælpsomt” at ændre ikke-relateret infrastruktur, når releasen fejler. Agenten kan foreslå en separat rettelse, men produktionshandlingen forbliver knyttet til én anmodning.

For gentagne releases bør du føre et lille release record i repositoryet eller change management-systemet. Registrér målet, kildebranchen, den forventede health path, den normale timeout og den godkendte recovery-handling. Et Claude Code-deployment er sikrere, når den næste session ikke skal rekonstruere disse oplysninger fra chathistorikken.

Verificér kontoafgrænsningen før den første skrivehandling

Workspaces er grænser for ejerskab og fakturering. Bed Claude Code om at vise whoami, vise services og angive det valgte workspace, før den ændrer noget. Pro-planen koster $20 om måneden med $20 i usage credit og er den anbefalede betalte plan; alle betalte planer tillader ubegrænsede workspaces, databases og deployments, mens CPU-, RAM- og diskforbrug måles pr. minut mod planens saldo.

Denne prismodel ændrer ikke sikkerhedsreglen: En agent bør inspicere forbrug og målområde, før den skalerer eller opretter flere ressourcer. Produktionsrapporten bør skelne mellem abonnementsplanen og det faktiske målte forbrug.

Gør workflowet klar til produktion

Installér skillen i det samme miljø, hvor Claude Code skal køre, verificér godkendelsen, og begynd med en service med lav risiko, hvor health-endpointet allerede er kendt.

npm install -g dockup-cli
dockup skill install

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

FAQ

Kan Claude Code deploye direkte til produktion med Dockup?

Ja. Installér Dockup-skillen, angiv et afgrænset DOCKUP_TOKEN, find det præcise project/service-mål, og kør deploy-kommandoen med --wait og --json.

Hvorfor skal Claude Code bruge --wait?

Uden --wait betyder et vellykket svar kun, at deploymentet er sat i kø. Med --wait afslutter Dockup kun med 0 efter succes og returnerer ellers strukturerede deploy_failed- eller deploy_timeout-fejl.

Kan Claude Code se gemte secret-værdier?

Dockup maskerer secret-værdier i output. Agenten kan angive eller erstatte en secret, men læsning af environment-konfiguration returnerer ikke den gemte secret-værdi.

Hvad sker der, når et repository ikke har en Dockerfile?

Dockup bruger Nixpacks til automatisk at registrere og builde applikationen. En Dockerfile i repositoryet har forrang, når den findes.

Hvordan kan Claude Code gendanne en dårlig release?

Den bør inspicere build- og runtime-logs, vise deploymenthistorikken og køre et kendt tidligere deployment igen med dockup rollback ved hjælp af det præcise deployment-ID.