Claude Code-deployment: produktionsguide

Claude Code-deployment blir tillförlitligt först när agenten kan skilja mellan ”begäran accepterad” och ”produktionen är frisk”. Dockup tillhandahåller detta deploymentlager genom ett CLI som är utformat för maskinella anrop: strukturerad JSON, riktiga process-exitkoder och ett --wait-läge som förblir anslutet tills ett deployment når ett slutgiltigt tillstånd.

Den här guiden tar ett repository från lokalt arbete till en verifierad produktionsrelease. Den definierar också vilka behörigheter Claude Code bör få, vilken evidens den ska returnera och när en människa måste godkänna en destruktiv åtgärd.

Vad behöver Claude Code-deployment innan produktion?

En coding agent bör inte börja med att gissa ett tjänstenamn eller klicka sig igenom en dashboard. Ge den i stället ett tydligt och avgränsat arbetsavtal: hitta det exakta målet, genomför en avsedd ändring, vänta på resultatet och rapportera maskinläsbar evidens.

De grundläggande förutsättningarna är enkla:

Krav	Varför det är viktigt	Verifiering
Node.js 18 eller senare	Krävs av Dockup CLI-paketet	node --version
Dockup-konto	Äger workspaces, tjänster och databaser	Logga in på app.dockup.ai
Git-repository	Källa för tjänstens build	Bekräfta remote-URL och branch
API-token	Icke-interaktiv autentisering	dockup whoami --json
Health-endpoint eller lyssnande port	Styr blue-green-cutover	dockup health ... --json

Fastställ produktionsgränsen innan agenten agerar. Claude Code kan skapa en tjänst, ange icke-hemlig konfiguration, starta ett deployment, inspektera loggar och föreslå en rollback. Den bör inte ta bort en tjänst, radera en databas eller rensa konfiguration utan uttryckligt godkännande från en människa.

Dockup förstärker den gränsen. Destruktiva kommandon vägrar att fortsätta utan --yes och returnerar felet needs_confirm i strukturerad form, i stället för att tolka utebliven bekräftelse som en uppmaning att improvisera. För en bredare policy, se produktionsskyddsräcken för AI-agenter.

Hur installerar man Claude Code-skillen och autentiserar säkert?

Installera CLI:t, installera den medföljande skillen och verifiera att skillen motsvarar den installerade binären:

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

Installationsprogrammet skriver den kanoniska skillen till ~/.agents/skills/dockup/ och länkar den till Claude Codes skill-katalog. Eftersom skillen levereras i samma npm-paket som CLI:t uppdaterar dockup update båda. Claude Code behöver inte förlita sig på en kopierad kommandoreferens som kan beskriva flaggor som den lokala binären inte stöder.

Använd en environment-token för autonoma sessioner:

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

Ett lyckat svar identifierar kontot och anger tokenSource som env. Klistra inte in token i en prompt, checka inte in den i repositoryt och skriv inte ut den i en CI-logg. Hemliga värden som lagras i Dockup maskeras när konfigurationen läses tillbaka.

Den fullständiga referensen för Dockup CLI är den auktoritativa kommandoytan. Med 135 kommandon bör Claude Code läsa den aktuella referensen och den paketerade skillen i stället för att förlita sig på ihågkomna flaggor.

Eftersom skillen levereras inuti CLI-paketet uppdaterar dockup update både den körbara filen och instruktionerna samtidigt. Denna versionssynkronisering är säkrare än att kopiera en kommandolista till en långlivad prompt.

Hur skapar Dockup CLI en tjänst från Git?

Be först agenten identifiera workspacet och undvika att konstruera sluggar från visningsnamn. Befintliga mål returneras av:

dockup services --json

För ett repository som aldrig har distribuerats kan en enda transaktion skapa tjänsten, distribuera den, vänta tills den är klar och länka den aktuella katalogen:

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

När repositoryt innehåller en Dockerfile använder Dockup den. Om en sådan saknas använder Dockup Nixpacks för automatisk build-detektering. Valet förklaras i Nixpacks jämfört med Dockerfile, inklusive när uttryckliga build-instruktioner är värda den extra underhållskostnaden.

Kör dockup services --json igen och inspektera det exakta målet innan du försöker skapa tjänsten på nytt efter en avbruten session. Om tjänsten redan finns ska du fortsätta från dess status i stället för att skicka ytterligare en create-begäran.

När repositoryt väl är länkat kan kommandon därifrån hitta målet via .dockup, men produktionsrunbooks bör fortfarande dokumentera det fullständiga värdet project/service. Discovery är den säkra gränsen mellan en osäker tidigare åtgärd och en ny förändring i produktionen.

Hur förbereder man environment variables, databaser och health checks?

Håll vanlig konfiguration åtskild från secrets. Claude Code kan ange ett publikt runtime-värde och en maskerad secret utan att senare skriva ut lagrade secret-värden:

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

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

Ändringar av environment variables börjar gälla vid nästa deployment. Det är avsiktligt: en körande container behåller sin aktuella processmiljö tills den ersätts. Det fullständiga arbetssättet beskrivs i environment variables och secrets.

Om applikationen behöver en hanterad PostgreSQL-databas skapar du den i det valda workspacet och läser dess information via de dokumenterade databaskommandona:

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

Private networking kan senare ge tjänster och databaser stabila värdnamn på formen <slug>.internal inom ett och samma projekt. Låt inte agenten hitta på en databas-URL; använd anslutningsinformationen som Dockup returnerar och lagra den som en secret.

Konfigurera en readiness-gate före den första viktiga produktionsreleasen:

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

Dockup genomför blue-green-deployment utan driftstopp och styr först trafiken till den nya versionen när health-gaten har passerats. Arkitekturen utforskas i deployments utan driftstopp.

Hur distribuerar Claude Code och bevisar att det lyckades?

Använd --wait; låt inte agenten tolka ”deployment köat” som ”applikationen körs”:

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

Standardtimeouten för vänteläget är 900 sekunder. Vid framgång avslutas kommandot med 0 och returnerar slutstatus, varaktighet, deployment-ID och URL. Om builden misslyckas avslutas det med en exitkod som inte är noll och code:"deploy_failed". Om operationen fortfarande pågår när timeouten nås avslutas det med en exitkod som inte är noll och code:"deploy_timeout".

En användbar instruktion till Claude Code är: ”Behandla processens exitkod som det primära resultatet och sammanfatta sedan JSON-fälten.” Det förhindrar optimistiska formuleringar när plattformen redan har returnerat ett fel.

Samla in tre oberoende signaler efter en lyckad körning:

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

status bekräftar tjänsten och statusen för det senaste deploymentet. uptime returnerar övervakningsstatistik minut för minut, inklusive genomsnittlig svarstid och p95. security visar den senaste CVE-skanningen av imagen och konfigurationsskanningen. Dessa kontroller kompletterar säkerhetsarbetet på applikationsnivå, men ersätter inte applikationstester.

Vad bör Claude Code göra när produktionen misslyckas?

Skilj på build-fel och runtime-fel. Vid en misslyckad build krävs den senaste build-loggen:

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

En container som byggdes men kraschar efter uppstart kräver runtime-output:

dockup logs production/my-api --json

Om du vill följa en build samtidigt som du behåller maskinläsbara batchar använder du NDJSON follow-läge:

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

Kommandot avslutas när deploymentet når ett slutgiltigt tillstånd och returnerar en exitkod som inte är noll om det misslyckades. Claude Code kan strömma förloppet utan att själv behöva hitta på en polling-loop.

Om den aktuella releasen är osund och ett känt tidigare deployment bör köras igen listar du historiken och använder dess exakta ID:

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

Agenten bör rapportera vilket deployment-ID den valde och varför. Rollback är ett operativt beslut, inte en ersättning för att förstå felet. Bevara build-loggen, runtime-loggen, exitkoden och audit-posten så att incidenten kan rekonstrueras.

En färdig rapport om Claude Code-deployment bör innehålla mål, commit eller branch, deployment-ID, slutstatus, URL, förfluten tid, health-resultat och eventuella kvarstående risker. Denna evidens gör en autonom åtgärd till en produktionsändring som går att granska.

Definiera ett completion contract för produktion

Ange det förväntade completion contractet i uppgiften innan du börjar. En användbar begäran är: distribuera det länkade repositoryt till production/my-api; vänta på ett slutgiltigt resultat; ta inte bort, rensa eller överför något; returnera felkoden och de sista 60 relevanta raderna från build-loggen vid fel; returnera status, URL, deployment-ID, varaktighet och health-evidens vid framgång.

Denna formulering ger Claude Code ett avgränsat mål och ett rapporteringsschema. Den hindrar också agenten från att ”hjälpsamt” ändra orelaterad infrastruktur när releasen misslyckas. Agenten kan föreslå en separat korrigering, men produktionsåtgärden förblir kopplad till en enda begäran.

För återkommande releaser bör du spara en liten releasepost i repositoryt eller i systemet för change management. Dokumentera mål, källbranch, förväntad health path, normal timeout och godkänd återställningsåtgärd. Ett Claude Code-deployment är säkrare när nästa session inte behöver återskapa dessa fakta från chatthistoriken.

Verifiera kontoavgränsningen före den första skrivningen

Workspaces är gränser för ägarskap och fakturering. Be Claude Code visa whoami, lista tjänster och ange det valda workspacet innan den ändrar något. Pro-planen kostar 20 dollar per månad och innehåller 20 dollar i användningskredit, och är den rekommenderade betalplanen. Alla betalplaner tillåter obegränsat antal workspaces, databaser och deployments, medan CPU-, RAM- och diskanvändning mäts per minut mot planens saldo.

Den prismodellen förändrar inte säkerhetsregeln: en agent bör inspektera användning och målomfattning innan den skalar eller skapar ytterligare resurser. Produktionsrapporten bör skilja på abonnemangsplanen och den faktiska uppmätta förbrukningen.

Ta arbetsflödet till produktion

Installera skillen i samma miljö som Claude Code ska köras i, verifiera autentiseringen och börja med en tjänst med låg risk där health-endpointen redan är känd.

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. Börja gratis på app.dockup.ai.

FAQ

Kan Claude Code distribuera direkt till produktion med Dockup?

Ja. Installera Dockup-skillen, ange en avgränsad DOCKUP_TOKEN, hitta det exakta project/service-målet och kör deploy-kommandot med --wait och --json.

Varför bör Claude Code använda --wait?

Utan --wait betyder ett lyckat svar bara att deploymentet har köats. Med --wait avslutas Dockup med 0 först efter en lyckad körning och returnerar annars strukturerade felen deploy_failed eller deploy_timeout.

Kan Claude Code se lagrade secret-värden?

Dockup maskerar secret-värden i output. Agenten kan ange eller ersätta en secret, men när environment-konfigurationen läses returneras inte det lagrade secret-värdet.

Vad händer när ett repository saknar Dockerfile?

Dockup använder Nixpacks för att automatiskt identifiera och bygga applikationen. En Dockerfile i repositoryt har företräde när den finns.

Hur kan Claude Code återställa en misslyckad release?

Den bör inspektera build- och runtime-loggar, lista deploymenthistoriken och köra ett känt tidigare deployment igen med dockup rollback och det exakta deployment-ID:t.