Ръководство за deployment на Claude Code в production

Deployment-ът на Claude Code е надежден само когато агентът може да различи „заявката е приета“ от „production е в добро състояние“. Dockup предоставя този deployment layer чрез CLI, създаден за машинни извиквания: структуриран JSON, реални process exit codes и режим --wait, който остава свързан, докато deployment-ът достигне крайно състояние.

Това ръководство проследява repository от локална работа до проверен production release. То също така определя какви permissions трябва да получи Claude Code, какви доказателства трябва да върне и в кой момент човек трябва да одобри destructive action.

Какво е необходимо на Claude Code преди production?

Coding agent не трябва да започва с отгатване на името на service или с обхождане на dashboard. Дайте му тесен operating contract: да открие точния target, да направи една предвидена промяна, да изчака резултата и да отчете machine-readable evidence.

Основните prerequisites са ясни:

Изискване	Защо е важно	Проверка
Node.js 18 или по-нова версия	Изисква се от Dockup CLI package	node --version
Dockup account	Притежава workspaces, services и databases	Влезте в app.dockup.ai
Git repository	Source за build-а на service	Потвърдете remote URL и branch
API token	Authentication без интеракция	dockup whoami --json
Health endpoint или listening port	Определя blue-green cutover-а	dockup health ... --json

Определете production границите, преди агентът да предприеме действие. Claude Code може да създава service, да задава non-secret configuration, да стартира deploy, да проверява logs и да предлага rollback. Не трябва да изтрива service, да премахва database или да премахва configuration без изрично човешко одобрение.

Dockup подсилва тази граница. Destructive commands отказват да продължат без --yes и връщат структурирана грешка needs_confirm, вместо да приемат липсващото потвърждение като покана за импровизация. За по-широка политика използвайте production guardrails за AI агенти.

Как да инсталирате Claude Code skill и да се удостоверите безопасно?

Инсталирайте CLI, инсталирайте bundled skill и проверете дали skill-ът съответства на инсталирания binary:

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

Installer-ът записва canonical skill в ~/.agents/skills/dockup/ и го свързва с skill directory на Claude Code. Тъй като skill-ът се доставя в същия npm package като CLI, dockup update обновява и двете. Claude Code не трябва да разчита на копирана command reference, която може да описва flags, неподдържани от локалния binary.

Използвайте environment token за autonomous sessions:

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

Успешният response идентифицира account-а и отчита tokenSource като env. Не поставяйте token-а в prompt, не го commit-вайте в repository и не го echo-вайте в CI log. Secret values, съхранявани в Dockup, се mask-ват при повторно прочитане на configuration.

Пълната reference документация за Dockup CLI е authoritative command surface. При 135 commands Claude Code трябва да се консултира с актуалната reference и packaged skill, вместо да разчита на запомнени flags.

Тъй като skill-ът се доставя в CLI package, dockup update обновява executable файла и инструкциите му едновременно. Това version alignment е по-безопасно от копирането на command list в дълготраен prompt.

Как Dockup CLI създава service от Git?

Първо поискайте от агента да идентифицира workspace и избягвайте създаването на slugs от display names. Съществуващите targets се връщат чрез:

dockup services --json

За repository, който никога не е бил deploy-ван, една transaction може да създаде service, да го deploy-не, да изчака завършването и да link-не текущата directory:

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

Когато repository съдържа Dockerfile, Dockup го използва. Ако няма такъв, Dockup преминава към Nixpacks за automatic build detection. Изборът е обяснен в Nixpacks срещу Dockerfile, включително кога explicit build instructions си заслужават maintenance cost.

Преди да повторите creation след прекъсната session, изпълнете отново dockup services --json и проверете точния target. Ако service вече съществува, продължете от неговия status, вместо да изпращате нова create request.

След като бъде link-нат, commands в това repository могат да откриват target-а от .dockup, но production runbooks все пак трябва да записват пълната стойност project/service. Discovery е безопасната граница между несигурно предишно действие и нова production mutation.

Как трябва да бъдат подготвени environment variables, databases и health checks?

Дръжте обикновената configuration отделно от secrets. Claude Code може да зададе public runtime value и masked secret, без по-късно да отпечатва съхранените secret values:

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 се прилагат при следващия deployment. Това е умишлено: работещият container запазва текущия си process environment, докато не бъде заменен. Пълният operating pattern е описан в environment variables и secrets.

Ако приложението се нуждае от managed PostgreSQL database, създайте я в избрания workspace и прочетете детайлите ѝ чрез документираните database commands:

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

Private networking по-късно може да предостави на services и databases стабилни <slug>.internal hostnames в рамките на един project. Не карайте агента да измисля database URL; използвайте connection information, върната от Dockup, и я съхранявайте като secret.

Конфигурирайте readiness gate преди първия важен production release:

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

Dockup изпълнява zero-downtime blue-green deployment и насочва traffic към новата версия едва след като health gate премине успешно. Архитектурата е разгледана в zero-downtime deployments.

Как Claude Code deploy-ва и доказва, че deployment-ът е успешен?

Използвайте --wait; не позволявайте на агента да тълкува „deployment-ът е queued“ като „приложението работи“:

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

Стандартният wait timeout е 900 секунди. При успех command-ът завършва с 0 и връща terminal status, duration, deployment ID и URL. Ако build-ът се провали, command-ът завършва с non-zero и code:"deploy_failed". Ако operation-ът все още се изпълнява при изтичане на timeout-а, command-ът завършва с non-zero и code:"deploy_timeout".

Полезна инструкция към Claude Code е: „Приемай process exit code за primary result; след това обобщи JSON fields.“ Така се предотвратява оптимистичен език, когато platform вече е върнала failure.

След успех съберете три независими сигнала:

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

status потвърждава service и състоянието на последния deployment. uptime връща minute-by-minute monitoring statistics, включително average response time и p95. security показва последния image CVE и configuration scan. Тези проверки допълват application-level security practices; не заменят application tests.

Какво трябва да направи Claude Code при failure в production?

Разделяйте build failure от runtime failure. При failed build е необходим последният build log:

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

Container, който е build-нат, но се crash-ва след startup, изисква runtime output:

dockup logs production/my-api --json

За да наблюдавате build, като същевременно запазите machine-readable batches, използвайте NDJSON follow mode:

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

Command-ът спира, когато deployment-ът достигне terminal state, и завършва с non-zero, ако е неуспешен. Claude Code може да stream-ва progress, без да създава polling loop.

Ако текущият release е unhealthy и трябва да бъде повторно стартиран известен предишен deployment, изведете history и използвайте точния му ID:

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

Агентът трябва да отчете кой deployment ID е избрал и защо. Rollback е operational decision, а не заместител на разбирането на failure-а. Запазете build log, runtime log, exit code и audit record, така че incident-ът да може да бъде реконструиран.

Завършеният deployment report на Claude Code трябва да включва target, commit или branch, deployment ID, terminal status, URL, elapsed time, health result и всички последващи рискове. Това evidence превръща autonomous action в production change, който може да бъде прегледан.

Дефинирайте production completion contract

Преди да започнете, включете очаквания completion contract в task-а. Полезна заявка е: deploy-вай link-натия repository към production/my-api; изчакай terminal result; не изтривай, не премахвай и не прехвърляй нищо; при failure върни error code и последните 60 релевантни реда от build log-а; при успех върни status, URL, deployment ID, duration и health evidence.

Тази формулировка дава на Claude Code ограничена цел и reporting schema. Тя също така предотвратява агентът да променя „услужливо“ несвързана инфраструктура, когато release-ът се провали. Агентът може да предложи отделен fix, но production action остава приписуемо на една заявка.

За повтарящи се releases поддържайте кратък release record в repository или в change-management system. Записвайте target, source branch, очаквания health path, normal timeout и approved recovery action. Deployment-ът на Claude Code е по-безопасен, когато следващата session не трябва да възстановява тези факти от chat history.

Проверете границата на account-а преди първия write

Workspaces са граници на ownership и billing. Накарайте Claude Code да покаже whoami, да изведе списък със services и да посочи избрания workspace, преди да мутира каквото и да е. Pro plan е $20 на месец с $20 usage credit и е препоръчителният платен plan; всички платени plans позволяват unlimited workspaces, databases и deployments, докато използването на CPU, RAM и disk се измерва на минута спрямо баланса на plan-а.

Този pricing model не променя правилото за безопасност: агентът трябва да провери usage и target scope, преди да мащабира или да създава допълнителни resources. Production report-ът трябва да разграничава subscription plan от реалното metered consumption.

Въведете workflow-а в production

Инсталирайте skill-а в същата environment, в която ще работи Claude Code, проверете authentication-а и започнете с low-risk service, чийто health endpoint вече е известен.

npm install -g dockup-cli
dockup skill install

Първата команда инсталира CLI. Втората инсталира съответстващия Dockup skill за Claude Code и Codex. Започнете безплатно от app.dockup.ai.

FAQ

Може ли Claude Code да deploy-ва директно в production с Dockup?

Да. Инсталирайте Dockup skill, предоставете scoped DOCKUP_TOKEN, резолвирайте точния project/service target и изпълнете deploy command с --wait и --json.

Защо Claude Code трябва да използва --wait?

Без --wait успешният response означава само, че deployment-ът е queued. С --wait Dockup завършва с 0 едва след успех и в противен случай връща структурирани грешки deploy_failed или deploy_timeout.

Вижда ли Claude Code съхранените secret values?

Dockup mask-ва secret values в output-а. Агентът може да зададе или замени secret, но прочитането на environment configuration не връща съхранената secret value.

Какво се случва, когато repository няма Dockerfile?

Dockup използва Nixpacks, за да открие и build-не приложението автоматично. Repository Dockerfile има приоритет, когато е наличен.

Как Claude Code може да се възстанови от неуспешен release?

Трябва да провери build и runtime logs, да изведе deployment history и да стартира повторно известен предишен deployment с dockup rollback, използвайки точния deployment ID.