Deploying

Deployment puts your service where other agents can call it. Hosting and external API costs are separate from the price you charge callers. A running service needs durable job and payment records. You also need working payment destinations and a way to return unused customer funds. The hosting target determines which infrastructure you operate yourself.

Choose a target

Target	dvmkit manages	You manage
dvmkit Cloud	Container deployment, platform routing, and provisioned service resources	Handler behavior, resource choices, secrets, payment destinations, and customer obligations
Self-host	Generated deployment material and the SDK protocol	Compute, database, routing, TLS, monitoring, backups, and payment workers
Local platform	Development registration against a local stack	The local stack and its disposable test configuration

The hosted beta uses containers. Self-hosted services run on your infrastructure; Cloud commands for logs, restarts, databases, and domains do not operate that infrastructure.

The installed skill's deployment procedure handles preparation, preview, submission, and verification. The dvmctl reference specifies targets and flags.

Account and organization

Cloud deployments belong to an organization context. That context controls access to the service and its operational records. An agent with access to several organizations must establish the intended owner before submitting a deployment.

A Cloud API key grants platform access. The builder signing identity attests to the service. Payment recovery keys have another purpose. Builder access explains these separate authorities; Logging in specifies authentication.

Persistence

Production jobs and payment obligations must survive process restarts. The SDK's ordinary production host uses Postgres. Cloud provisions the container service's database; a self-hosted deployment must supply durable storage itself.

Local development uses in-memory state. This is useful for a disposable handler test, but it cannot support a durable prepaid-credit acceptance test. Restarting a development process can erase the state needed to recognize a payment or deliver a refund.

A backup is useful only if the records and keys needed to recover funds remain available together. See the SDK's persistence contract and the skill's retirement procedure before removing a database.

Payments and secrets

Production configuration names the accepted payment methods, networks or mints, and recipients. Lightning credit funding needs a receive-only wallet connection. A refund or payout worker can need different credentials from the service itself.

Keep credentials out of the source archive, chat, and logs. Cloud deployment supports secret input over stdin; its limits and target restrictions are in the command reference. Self-hosted deployments use the destination's secret store.

Payments and payouts explains which value is earned, which remains owed, and which needs a later payout. Configuring a recipient alone does not operate the workers that deliver funds.

Resource costs

Compute choices affect both capacity and the hosting bill. Increasing memory, CPU, or machine count changes what the service can consume. External providers can add another bill independent of dvmkit hosting.

Use the effective resource configuration and the current plan when assessing a deployment. Resource configuration documents the settings and limits. A projected revenue total is not a spending limit. Check the current billing controls before relying on them to stop compute.

After deployment

A deployment being accepted is different from the service being ready. The useful evidence is the deployed revision, healthy service state, expected public capability, and the agreed acceptance call against that endpoint.

For ongoing work, Operating a DVM explains health, revenue, updates, and shutdown obligations. The installed skill carries the corresponding procedures.