Розгортання Codex: повний workflow у Dockup

Розгортання Codex має завершуватися доказами, а не припущеннями. Практична проблема полягає не в тому, щоб попросити Codex виконати команду deploy, а в тому, щоб надати агенту інтерфейс, який визначає точну ціль, очікує на terminal state, повертає реальні exit codes і показує деталі помилки без браузера.

Dockup — це deployment layer для такого workflow. Його CLI повертає Codex структурований JSON для кожної підтримуваної команди, а вбудований skill навчає агента автентифікуватися, знаходити сервіси, виконувати deploy, діагностувати проблеми й зупинятися перед деструктивними операціями.

Як інсталювати skill для Codex CLI?

Спочатку інсталюйте CLI глобально, а потім запустіть єдиний інсталятор skill. Він записує canonical skill і додає на нього посилання в Claude Code та Codex:

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

Canonical skill розташований у ~/.agents/skills/dockup/, а символічне посилання на нього створюється в ~/.codex/skills/. Skill постачається всередині dockup-cli, тому звичайне оновлення одночасно змінює executable та його інструкції:

dockup update

Такий зв’язок версій важливий за великої кількості команд і параметрів. Агент не має виконувати прапорець, який запам’ятав, лише тому, що той зустрічався в старому prompt. Codex має використовувати запакований skill і актуальний довідник Dockup CLI як джерело достовірних відомостей про команди.

Обґрунтування підходу зі skills див. у статті skills агентів проти MCP.

Як Codex автентифікується без інтерактивного термінала?

Sandbox або CI job може не мати змоги завершити browser-based login. Установіть token у середовищі процесу:

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

DOCKUP_TOKEN має пріоритет над локальним config file. Відповідь whoami показує, чи надійшли активні credentials із середовища або з config, що допомагає Codex діагностувати поширену ситуацію, коли одночасно існують застарілий локальний token і CI token.

Ставтеся до token як до infrastructure secret. Не додавайте його в AGENTS.md, SKILL.md, систему контролю версій, приклади команд, закомічені в repository, або фінальний transcript агента. У CI використовуйте зашифроване сховище secrets платформи й передавайте значення лише кроку розгортання. Повний non-interactive pattern описано в матеріалі CI/CD із DOCKUP_TOKEN.

Перш ніж надавати Codex доступ на запис, визначте межі його permissions. Доцільний початковий scope включає пошук сервісів, deployment, читання логів і перевірку статусу. Видалення баз даних, знищення сервісів, зміни команд і очищення config мають залишатися операціями, що потребують approval.

Як Codex знаходить або створює потрібний сервіс?

Пошук має бути першою операцією. Не просіть Codex перетворити “Payments API” на вгаданий slug:

dockup services --json

Кожен результат містить точне значення target у форматі project/service. Codex має скопіювати це значення в наступні команди й повернути його у своєму summary.

Якщо сервісу немає, створіть його з Git:

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

Команда створює сервіс, виконує його deployment, очікує завершення deployment і записує посилання .dockup у робочий каталог. Якщо Dockerfile присутній, використовується він; інакше Nixpacks автоматично визначає спосіб build.

Якщо Codex втрачає стан сесії або workflow запускається повторно після мережевого збою, він має знову знайти сервіси й перевірити точний target, перш ніж щось змінювати. Якщо target уже існує, продовжуйте на основі його status і deployment history замість повторного надсилання create request.

Повна послідовність repository-first доступна в матеріалі Від Git repository до production.

Як Codex має підготувати configuration перед deployment?

Попросіть Codex перевірити поточні metadata сервісу перед внесенням змін:

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

Відповідь про середовище містить ключі та markers isSecret, а значення secrets залишаються masked. Codex може додавати звичайні змінні та secrets окремо:

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

Ніколи не додавайте production secret у dockup.yaml; manifest призначений для конфігурації у відкритому вигляді, яку можна перевірити, а не для credentials. Наявні secret variables не перезаписуються й не видаляються workflow config-as-code.

Налаштуйте listening port сервісу та readiness check, якщо їхні значення відомі:

dockup set production/payments-api --port 3000 --json
dockup health production/payments-api \
  --path /health \
  --interval 5 \
  --retries 5 \
  --json

Readiness gate робить перевірку production змістовною. Платформа виконує blue-green deployment і спрямовує traffic лише після того, як нова версія проходить gate.

Як production verification підтверджує terminal state?

Для наявного сервісу використовуйте одну команду:

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

Явно вказаний timeout відповідає значенню за замовчуванням — 900 секундам — і робить намір workflow очевидним. Exit 0 означає успішний deployment. Ненульовий результат із deploy_failed означає, що build або deploy завершився помилкою. deploy_timeout означає, що на момент завершення періоду очікування операція все ще не перейшла в terminal state.

Правильна branching logic для Codex ґрунтується на статусі процесу:

Результат	Дія Codex
Exit 0, status:"success"	Перейти до перевірки health, uptime і security
deploy_failed	Прочитати build logs і визначити першу помилку, яку можна виправити
deploy_timeout	Повідомити про невизначеність; перевірити status або повторити спробу з обґрунтованим timeout
not_logged_in	Зупинитися й запросити дійсний token
needs_confirm	Зупинитися й попросити схвалення людини

Після успішного розгортання Codex зберіть спостережувані докази:

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

Uptime checks виконуються щохвилини й містять статистику часу відповіді, зокрема p95. Результати security містять CVE образу та перевірки configuration. Ці сигнали не доводять коректність бізнес-логіки, тому Codex також має запускати власні smoke tests repository, якщо вони доступні.

Як Codex має діагностувати помилковий release і відновлюватися після нього?

Build errors і runtime errors потребують різних логів. Використовуйте останній build output, якщо deployment не дійшов до контейнера, здатного запуститися:

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

Використовуйте runtime logs, якщо image зібрався, але application crash-иться, слухає неправильний port або завершується з помилкою після запуску:

dockup logs production/payments-api --json

Follow mode корисний під час тривалого build:

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

У JSON mode follow output має формат NDJSON, завдяки чому Codex може обробляти кожен batch одразу після надходження. Stream завершується на terminal deployment state і зберігає реальний failure exit code.

Відновлення слід починати з history, а не з вгадування target для rollback:

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

Codex має визначити відомий успішний deployment, вказати вибраний ID і зберегти докази помилки перед повторним запуском. Він ніколи не має вибирати “другий елемент” без перевірки status і timestamps.

Корисний фінальний звіт містить сім полів: target, branch або commit, deployment ID, exit code, terminal status, production URL і наступні дії. Такий формат робить кожне розгортання Codex доступним для перевірки людиною або наступним automation step.

Компактний verification script

Цей shell pattern об’єднує deployment і діагностику в один прозорий control flow:

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

Скрипт не шукає success sentence за допомогою grep. Він покладається на exit code CLI, зберігає deployment JSON і завершує з помилкою job, що його викликав, якщо production не досяг успішного стану.

Зробіть retries видимими, а не непомітними

Сесії агентів можуть перерватися після початку операції, але до того, як результат потрапить у transcript. Наступний запуск Codex не має сліпо повторювати кожну mutation. Він має знову знайти сервіс, перевірити останній deployment і визначити, чи перейшла попередня операція в terminal state.

Runbook для розгортання Codex має класифікувати команди як безпечні для повторення, безпечні лише після перевірки або такі, що потребують approval. Read operations безпечно повторювати. Створення сервісу спочатку потребує discovery. Новий deploy — це нова production event, і його слід так і фіксувати. Pruning та інші деструктивні операції залишаються рішеннями людини.

Відокремлюйте platform verification від application verification

Dockup може підтвердити, що build завершився, container став ready, а probes щохвилини спостерігають за публічним сервісом. Codex все одно має виконувати application-specific checks: public health endpoint, authenticated test request або smoke test із repository, який не змінює дані клієнтів.

Фінальний результат має описувати обидва рівні. “Platform deployment succeeded” і “application smoke test passed” — це різні твердження. Якщо доступне лише перше, Codex має прямо це зазначити, а не перетворювати невизначеність на green check mark.

Підтверджуйте доступний набір команд перед automation

Повторно використовуване завдання Codex має починатися з перевірки dockup skill status --json і відкриття актуального довідника CLI, якщо воно залежить від менш знайомої опції. Це не дає сесії дотримуватися прикладу, написаного для іншого release.

Така перевірка особливо корисна в ephemeral runners, де нова глобальна npm installation може відрізнятися від установленої на laptop розробника. Codex може повідомити стан skill до виконання першого production write, зробивши запис про deployment відтворюваним.

Фінальна передача

Зберігайте докази.

Не приховуйте target

Поверніть точний service target у фінальному звіті.

Зберігайте рішення щодо джерела

Зафіксуйте, чи використовував Dockup Dockerfile repository або Nixpacks. Цей факт допоможе наступній сесії Codex вибрати правильний build log і не сплутати зміну структури source із platform incident.

Також зафіксуйте, чи ввімкнено automatic deploy on push. Інакше manual agent release і push-triggered release можуть накластися та створити дві production events у межах одного розслідування.

Виведіть workflow у production

Виконайте перше розгортання Codex для disposable або low-risk сервісу, а потім перенесіть той самий перевірений command contract у production.

npm install -g dockup-cli
dockup skill install

Перша команда інсталює CLI. Друга інсталює відповідний Dockup skill для Claude Code та Codex. Почніть безкоштовно на app.dockup.ai.

FAQ

Чи може Codex розгорнути новий Git repository однією командою?

Так. dockup create може створити сервіс, виконати його deployment, дочекатися terminal result і додати посилання на поточний каталог, якщо використати --deploy, --wait і --link.

Як Codex має автентифікуватися в Dockup?

Використовуйте DOCKUP_TOKEN у середовищі процесу й перевірте його за допомогою dockup whoami --json. Це дає змогу уникнути інтерактивного browser login у sandbox і CI.

Що підтверджує успішність розгортання Codex?

Команда deploy має завершитися з exit 0 після запуску з --wait, а її JSON має повідомити про успішний terminal status. Після цього виконайте status, uptime і application smoke checks.

Чи може Codex прочитати production secrets із Dockup?

Ні. Значення secrets masked у output. Codex може встановити або замінити secret, але не отримує збережене значення під час перегляду configuration.

Що Codex має робити з needs_confirm?

Він має зупинитися й запросити явне схвалення людини. Ця помилка означає, що деструктивну команду було спробувано виконати без обов’язкового підтвердження --yes.