Claude Code Deployment: produksjonsveiledning

Claude Code-deployment blir pålitelig først når agenten kan skille mellom «forespørsel godtatt» og «produksjonen er frisk». Dockup tilbyr dette deploymentlaget gjennom en CLI utformet for maskinelle kallere: strukturert JSON, reelle prosess-exit codes og en --wait-modus som forblir tilkoblet til en deployment når en terminaltilstand.

Denne veiledningen tar et repository fra lokalt arbeid til en verifisert produksjonsrelease. Den definerer også hvilke tillatelser Claude Code bør få, hvilken dokumentasjon den skal returnere, og når et menneske må godkjenne en destruktiv handling.

Hva trenger Claude Code-deployment før produksjon?

En coding agent bør ikke begynne med å gjette et tjenestenavn eller klikke seg gjennom et dashboard. Gi den en avgrenset arbeidsavtale: finn det nøyaktige målet, gjør én tilsiktet endring, vent på resultatet og rapporter maskinlesbar dokumentasjon.

De grunnleggende forutsetningene er enkle:

Krav	Hvorfor det er viktig	Verifisering
Node.js 18 eller nyere	Kreves av Dockup CLI-pakken	node --version
Dockup-konto	Eier workspaces, tjenester og databaser	Logg inn på app.dockup.ai
Git-repository	Kilde for tjenestebuilden	Bekreft remote-URL og branch
API-token	Ikke-interaktiv autentisering	dockup whoami --json
Health-endepunkt eller port som lytter	Styrer blue-green cutover	dockup health ... --json

Fastsett produksjonsgrensen før agenten gjør noe. Claude Code kan opprette en tjeneste, angi ikke-hemmelig konfigurasjon, starte en deployment, inspisere logger og foreslå en rollback. Den bør ikke slette en tjeneste, fjerne en database eller rydde bort konfigurasjon uten uttrykkelig godkjenning fra et menneske.

Dockup forsterker denne grensen. Destruktive kommandoer nekter å fortsette uten --yes og returnerer en strukturert needs_confirm-feil i stedet for å tolke manglende bekreftelse som en invitasjon til å improvisere. Se produksjonsvern for AI-agenter for en bredere policy.

Hvordan installerer du Claude Code-skillen og autentiserer sikkert?

Installer CLI-en, installer den medfølgende skillen og bekreft at skillen samsvarer med den installerte binærfilen:

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

Installeringsprogrammet skriver den kanoniske skillen til ~/.agents/skills/dockup/ og lenker den inn i Claude Code sin skill-katalog. Ettersom skillen leveres i samme npm-pakke som CLI-en, oppdaterer dockup update begge. Claude Code trenger ikke stole på en kopiert kommandoreferanse som kanskje beskriver flagg den lokale binærfilen ikke støtter.

Bruk et miljøtoken for autonome sessions:

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

Et vellykket svar identifiserer kontoen og rapporterer tokenSource som env. Ikke lim tokenet inn i en prompt, commit det til repositoryet eller skriv det ut i en CI-logg. Hemmelige verdier som lagres i Dockup, maskeres når konfigurasjonen leses tilbake.

Den komplette Dockup CLI-referansen er den autoritative kommandooversikten. Med 135 kommandoer bør Claude Code slå opp den oppdaterte referansen og den pakkede skillen i stedet for å stole på huskede flagg.

Ettersom skillen leveres inne i CLI-pakken, oppdaterer dockup update den kjørbare filen og instruksjonene samtidig. Denne versjonssamsvaringen er sikrere enn å kopiere en kommandoliste inn i en langvarig prompt.

Hvordan oppretter Dockup CLI en tjeneste fra Git?

Be først agenten identifisere workspacet og unngå å konstruere slug-er fra visningsnavn. Eksisterende mål returneres av:

dockup services --json

For et repository som aldri har blitt deployet, kan én transaksjon opprette tjenesten, deploye den, vente på at den blir ferdig og lenke den gjeldende katalogen:

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

Når repositoryet inneholder en Dockerfile, bruker Dockup den. Uten en slik fil bruker Dockup Nixpacks som fallback for automatisk build-detektering. Valget forklares i Nixpacks versus Dockerfile, inkludert når eksplisitte build-instruksjoner er verdt vedlikeholdskostnaden.

Kjør dockup services --json på nytt og inspiser det nøyaktige målet før du prøver å opprette tjenesten på nytt etter en avbrutt session. Hvis tjenesten allerede finnes, fortsett fra statusen i stedet for å sende en ny create-forespørsel.

Når repositoryet er lenket, kan kommandoer der løse målet fra .dockup, men produksjonsrunbooks bør fortsatt registrere hele project/service-verdien. Discovery er den sikre grensen mellom en usikker tidligere handling og en ny mutasjon i produksjonen.

Hvordan klargjør du miljøvariabler, databaser og helsesjekker?

Hold vanlig konfigurasjon atskilt fra secrets. Claude Code kan angi en offentlig runtime-verdi og en maskert secret uten å skrive ut lagrede secret-verdier senere:

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

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

Miljøendringer tas i bruk ved neste deployment. Det er tilsiktet: En kjørende container beholder sitt nåværende prosessmiljø til den erstattes. Hele driftsmønsteret er beskrevet i miljøvariabler og secrets.

Hvis applikasjonen trenger en administrert PostgreSQL-database, oppretter du den i det valgte workspacet og leser detaljene gjennom de dokumenterte databasekommandoene:

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

Privat nettverk kan senere gi tjenester og databaser stabile <slug>.internal-vertsnavn innenfor ett prosjekt. Ikke la agenten finne på en database-URL; bruk tilkoblingsinformasjonen Dockup returnerer, og lagre den som en secret.

Konfigurer en readiness gate før den første viktige produksjonsreleasen:

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

Dockup utfører blue-green deployment uten nedetid og sender først trafikk til den nye versjonen etter at helsesjekken er bestått. Arkitekturen utforskes i deployments uten nedetid.

Hvordan deployer Claude Code og beviser at deploymenten lyktes?

Bruk --wait; ikke la agenten tolke «deployment lagt i kø» som «applikasjonen kjører»:

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

Standard timeout for venting er 900 sekunder. Ved suksess avslutter kommandoen med 0 og returnerer terminalstatus, varighet, deployment-ID og URL. Hvis builden mislykkes, avslutter den med en non-zero-verdi og code:"deploy_failed". Hvis operasjonen fortsatt pågår når timeouten utløper, avslutter den med en non-zero-verdi og code:"deploy_timeout".

En nyttig Claude Code-instruksjon er: «Behandle prosessens exit code som det primære resultatet, og oppsummer deretter JSON-feltene.» Det hindrer optimistisk språk når plattformen allerede har returnert en feil.

Etter suksess henter du tre uavhengige signaler:

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

status bekrefter tjenestens og den nyeste deploymentens tilstand. uptime returnerer overvåkingsstatistikk minutt for minutt, inkludert gjennomsnittlig svartid og p95. security viser den nyeste CVE-en for imaget og resultatet av konfigurasjonsskanningen. Disse kontrollene supplerer sikkerhetspraksis på applikasjonsnivå; de erstatter ikke applikasjonstester.

Hva bør Claude Code gjøre når produksjonen feiler?

Skill mellom build-feil og runtime-feil. En mislykket build krever den nyeste build-loggen:

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

En container som ble bygget, men krasjer etter oppstart, krever runtime-output:

dockup logs production/my-api --json

For å følge en build samtidig som du beholder maskinlesbare batches, bruker du NDJSON follow-modus:

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

Kommandoen stopper når deploymenten når en terminaltilstand og avslutter med en non-zero-verdi hvis den mislyktes. Claude Code kan strømme fremdriften uten å finne på en polling-loop.

Hvis den gjeldende releasen er usunn og en kjent tidligere deployment bør kjøres på nytt, viser du historikken og bruker den nøyaktige ID-en:

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

Agenten bør rapportere hvilken deployment-ID den valgte, og hvorfor. Rollback er en driftsbeslutning, ikke en erstatning for å forstå feilen. Ta vare på build-loggen, runtime-loggen, exit code og revisjonssporet slik at hendelsen fortsatt kan rekonstrueres.

En ferdig Claude Code-deploymentrapport bør inneholde mål, commit eller branch, deployment-ID, terminalstatus, URL, medgått tid, helseresultat og eventuell oppfølgingsrisiko. Denne dokumentasjonen gjør en autonom handling til en produksjonsendring som kan gjennomgås.

Definer en fullføringskontrakt for produksjon

Før du starter, tar du med den forventede fullføringskontrakten i oppgaven. En nyttig forespørsel er: deploy det lenkede repositoryet til production/my-api; vent på et terminalresultat; ikke slett, rydd bort eller overfør noe; returner feilkoden og de siste 60 relevante linjene fra build-loggen ved feil; returner status, URL, deployment-ID, varighet og helsedokumentasjon ved suksess.

Denne formuleringen gir Claude Code et avgrenset mål og et rapporteringsskjema. Den hindrer også agenten i å «hjelpe til» ved å endre ikke-relatert infrastruktur når releasen feiler. Agenten kan foreslå en separat retting, men produksjonshandlingen forblir knyttet til én forespørsel.

For gjentatte releaser bør du oppbevare en liten release-post i repositoryet eller endringshåndteringssystemet. Registrer målet, kildebranchen, forventet health path, normal timeout og godkjent gjenopprettingshandling. En Claude Code-deployment er tryggere når neste session ikke må rekonstruere disse faktaene fra chatteloggen.

Bekreft kontogrensen før den første skrivehandlingen

Workspaces er grenser for eierskap og fakturering. Be Claude Code vise whoami, liste tjenester og oppgi det valgte workspacet før den endrer noe. Pro-planen koster 20 dollar per måned og inkluderer 20 dollar i brukskreditt, og er den anbefalte betalte planen. Alle betalte planer tillater ubegrenset antall workspaces, databaser og deployments, mens CPU-, RAM- og diskbruk måles per minutt mot planens saldo.

Denne prismodellen endrer ikke sikkerhetsregelen: En agent bør kontrollere forbruk og målområde før den skalerer eller oppretter flere ressurser. Produksjonsrapporten bør skille mellom abonnementsplanen og faktisk målt forbruk.

Ta arbeidsflyten i bruk i produksjon

Installer skillen i samme miljø som Claude Code skal kjøre i, bekreft autentiseringen og begynn med en tjeneste med lav risiko, der health-endepunktet allerede er kjent.

npm install -g dockup-cli
dockup skill install

Den første kommandoen installerer CLI-en. Den andre installerer den tilhørende Dockup-skillen for Claude Code og Codex. Kom i gang gratis på app.dockup.ai.

Vanlige spørsmål

Kan Claude Code deploye direkte til produksjon med Dockup?

Ja. Installer Dockup-skillen, oppgi et avgrenset DOCKUP_TOKEN, finn det nøyaktige project/service-målet og kjør deploy-kommandoen med --wait og --json.

Hvorfor bør Claude Code bruke --wait?

Uten --wait betyr et vellykket svar bare at deploymenten er lagt i kø. Med --wait avslutter Dockup med 0 først etter suksess og returnerer strukturerte deploy_failed- eller deploy_timeout-feil ellers.

Ser Claude Code lagrede secret-verdier?

Dockup maskerer secret-verdier i output. Agenten kan angi eller erstatte en secret, men lesing av miljøkonfigurasjonen returnerer ikke den lagrede secret-verdien.

Hva skjer når et repository ikke har noen Dockerfile?

Dockup bruker Nixpacks til å oppdage og bygge applikasjonen automatisk. En Dockerfile i repositoryet har forrang når den finnes.

Hvordan kan Claude Code gjenopprette etter en mislykket release?

Den bør inspisere build- og runtime-logger, vise deploymenthistorikken og kjøre en kjent tidligere deployment på nytt med dockup rollback ved hjelp av den nøyaktige deployment-ID-en.