release runs the full .agentkit/agentkit.yaml release pipeline: scaffold release config, build the image in the cloud, create or update the AgentKit Runtime, and optionally release Feishu, WeCom, DingTalk proxies or a frontend BFF. If you use the root agentkit.yaml lifecycle config, use launch instead.
Run from the application project root with management credentials and permissions for builds, the registry, object storage, and runtimes. This flow does not read model environment variables from the root lifecycle configuration; declare them explicitly in .agentkit/agentkit.yaml under envs
The generated Python Dockerfile starts main.py by default. For another entry file, update its startup command in .agentkit/Dockerfile. An existing root Dockerfile takes precedence
release
Without a subcommand, release runs the full pipeline. If .agentkit/agentkit.yaml is missing, it first generates the config and asks you to review it before running the command again.
release creates or updates cloud runtimes and may create VeFaaS functions, gateways, container registry resources, TOS objects, and identity configuration. Confirm .agentkit/agentkit.yaml, credentials, region, and project before running it.
--json is only for managed Sidecar releases where .agentkit/agentkit.yaml resolves a harness_sidecar configuration. Using this flag with a standard release configuration returns a failure result. Output is newline-delimited JSON with progress, runtime, and terminal result events, so Studio or CI can render build, deploy, and publish status by phase.
release config
Generate .agentkit/agentkit.yaml and a Dockerfile.
release build
Build the image in the cloud from .agentkit/agentkit.yaml and write build artifacts under .agentkit/artifacts/.
Managed Harness Sidecar uses the compatible SDK, ADK, MCP, Starlette, and VeADK versions provided by its base image. Application installation adds business dependencies, and the build checks platform dependency version boundaries
Managed Sidecar builds must use the current .agentkit/Dockerfile generated by the CLI. If the project uses a user-owned root Dockerfile, or an older .agentkit/Dockerfile no longer matches the current managed build structure, release build fails before the cloud build starts. Run agentkit release config --force to generate the current template, and preserve any Dockerfile changes you maintain manually before replacing the file.
Cloud builds upload the build context to TOS before starting Code Pipeline. The CLI sizes the upload timeout from the compressed archive size, with a minimum of 120 seconds and a maximum of 10 minutes, and automatically retries once after retryable network errors such as connection resets, transient DNS failures, or upload timeouts. Managed Sidecar builds also retry one transient TOS bucket-read failure and use a dedicated cache-enabled Code Pipeline; that pipeline is isolated by the managed base image digest so it does not share cache with ordinary no-cache builds or builds that use another base image. If infrastructure.code_pipeline.pipeline_id pins an existing pipeline, managed Sidecar builds first verify that the selected pipeline is compatible with the current build contract. A missing or incompatible pinned pipeline fails closed instead of falling back to another pipeline.
release apply
Create or update the runtime from the latest built artifact.
For managed Harness Sidecar releases, release apply waits for the key_auth APIG binding after the runtime reaches Ready, then runs the Sidecar, enabled model proxy, and required MCP gateway checks. If the release API response is ambiguous but the runtime is already releasing or the new version is ready, the CLI continues from the observed runtime state instead of triggering the release again.
When an existing Sidecar runtime is in Error, but the current version is still the only serving Ready version and every newer version has failed, the CLI preserves the current serving version and updates in place to a new version. If a newer non-failed version exists, more than one serving instance is present, or the recovery conditions cannot be confirmed, the command fails and requires explicit runtime reconciliation first.
IM channel and frontend release settings still live in .agentkit/agentkit.yaml; see agentkit.yaml for field details.
Readiness and runtime roles
For runtime creation, an explicit IAM role must exist. Otherwise the CLI reuses a role with AgentKitDefaultRuntimeAccess or creates a new one. Updates retain the existing role without modifying its policies automatically; scheduled tasks configure their required TOS prefix permissions separately
The default readiness wait is 15 minutes. Override it with a positive integer in milliseconds using AGENTKIT_RUNTIME_READY_TIMEOUT_MS. Check runtime status after a client timeout before creating resources again
Managed Sidecar supports Beijing deployments, private-only gateway bindings, and existing header-based API-key authentication. Builds resolve the image digest into the artifact record and fail if the image is not visible in the registry. Temporary TOS source archives are cleaned up at the end; cleanup failure after a successful build is also reported as an error
Scaffolding writes local files only. A successful release build produces an artifact; a successful release apply completes publication. Finally, inspect agentkit runtime show <name> and verify a real call. If a messaging proxy or frontend step fails, inspect runtimes and functions already created rather than assuming the entire flow left no resources
release config --force overwrites generated release configuration and the applicable Dockerfile. Save custom fields and changes before regenerating
