Skip to main content
agentkit.yaml is the single source of deploy configuration. Scaffold a project with agentkit init first, then run agentkit deploy config to generate it under the project’s .agentkit/ directory; agentkit deploy, deploy build, and deploy apply all read from it — no extra flags required. In the generated file, required and common fields are active; every optional field is shown commented-out with its full shape, so you uncomment and fill it to enable it. Secrets are not written in plaintext; instead, reference the deploy environment with ${VAR}, resolved by the CLI at deploy time:
  • ${VAR} — required; the deploy fails if it is unset;
  • ${VAR:-default} — use the default when unset or empty;
  • ${VAR:?message} — required; fail with message when unset;
  • $$ — a literal $.
The CLI loads the project’s .env (from the working directory) before resolving these, so it is enough to put the values in .env — no manual export is needed. Variables already set in your shell take precedence, and .env is never uploaded to the runtime.

Full example

.agentkit/agentkit.yaml

Project

The top-level identifiers, all required. cloud_provider selects one provider for the entire deployment. Resource blocks can override only region and project; mixing providers in one deployment is unsupported. An explicit command-line --provider takes precedence over environment detection and is written to newly generated configuration.

Runtime resources

The runtime block configures compute resources and the scaling policy.

Runtime network

runtime.network is optional. Before enabling a private network, make sure the VPC, subnets, and security groups are in the Runtime region.

Environment variables

envs declares the environment variables injected into the runtime. To keep secrets out of the repository, reference the deploy environment with ${VAR} (syntax at the top of this page); the CLI resolves them at deploy time.
For how to supply the values, see Build & deploy · Environment variables: for a local deploy, export the variables or put them in a local .env; in continuous deployment, configure them as repository secrets. The VOLCENGINE_* deploy credentials are not injected into the runtime.
${VAR} replaces the older AK_-prefix injection: each variable is now declared explicitly in envs and read via ${VAR}, which is clearer and reviewable. Secrets in the auth, im, and frontend blocks use ${VAR} the same way.

Model and associated resources

All optional — specify the model the runtime uses and the platform resources it attaches.

Gateway auth

auth configures the runtime gateway’s authentication, one type of two. When frontend (below) is enabled, gateway auth is set to custom_jwt automatically from its userpool, so you do not repeat it here.

IM channels

The im block deploys a bot proxy to VeFaaS after the runtime to connect a messaging channel. Provide credentials via ${VAR}. Feishu, WeCom, and DingTalk are supported; enable any combination. im.region and im.project can override the top-level region and project.

Feishu

WeCom

The WeCom proxy connects over WebSocket. The endpoint (websocket_url, default wss://openws.work.weixin.qq.com) and whether to send an interim “thinking” message (send_thinking_message, default true) can also be set but are rarely needed.

DingTalk

Frontend

The frontend block deploys a public front door on VeFaaS: OAuth login at the edge, then reverse-proxy to the runtime forwarding the user’s JWT (no shared key). Once enabled, the runtime gateway auth is set to custom_jwt from this userpool, the callback is auto-registered, and OAUTH2_REDIRECT_URI is auto-derived, so you only declare the userpool here.

Observability

Set apmplus to true to enable APMPlus monitoring.

Advanced

Infrastructure

infrastructure specifies where the image is built and stored. Auto means the platform creates and manages it for you; replace a value with your own resource to reuse one.

Build

The dockerfile field sets the path to the Dockerfile used for the build, defaulting to .agentkit/Dockerfile (or ./Dockerfile if one exists at the project root). For how the container starts and the requirement to listen on 0.0.0.0:8000, see Build & deploy · Container entrypoint and port.
Last modified on September 19, 2026