Skip to content

x/deployment — Deployment module

The x/deployment module holds what a tenant wants to run: a deployment specification enumerating one or more groups of services, each with resource requirements (CPU, memory, storage), placement constraints, and pricing bounds. When a tenant creates a deployment, the module emits the orders that the market module opens for bidding.

Deployments are versioned, updatable state. Group-level granularity means a single deployment can fan out to multiple orders placed with different providers in different regions.

The module stores declarative workload descriptions and translates them into marketplace primitives:

  • A deployment spec enumerates groups of services with CPU, memory, and storage requirements, placement constraints, and pricing bounds.
  • Each group fans out to an independently biddable order with its own placement rules, opened for competitive bidding by x/market.
  • The deployment funds the escrow account that backs its resulting leases, so demand arrives with budget attached.

Deployments are versioned and updatable: tenants can update specs as needs change or close the deployment, with unspent escrow returning to the tenant.

Tenants think in terms of workloads, not individual orders. The deployment module translates a declarative workload description into marketplace primitives, the same way a Kubernetes Deployment translates a desired state into pods — but with the exchange, not a scheduler, deciding who runs it.

ConceptDefinition
DeploymentA tenant’s declarative description of the services they want the marketplace to run.
GroupA subdivision of a deployment that becomes an independently-biddable order with its own placement rules.
SDLThe stack definition language in which workloads are described — services, resources, and placement.
  1. Describe — Write the spec. Services, resources, placement, and pricing bounds declared in the stack definition language.
  2. Emit — Groups become orders. Each group fans out to an order that the market module opens for competitive bidding.
  3. Fund — Fund the escrow. The deployment funds the escrow account backing its resulting leases — demand arrives with budget attached.
  4. Run — Update or close. Deployments are versioned: update specs as needs change or close out, with unspent escrow returning to the tenant.
MessagePurpose
MsgCreateDeploymentCreates a deployment from a tenant’s workload specification.
MsgUpdateDeploymentUpdates a deployment’s versioned specification.
MsgCloseDeploymentCloses a deployment; unspent escrow returns to the tenant.
MsgStartGroupStarts a group within a deployment.
MsgPauseGroupPauses a running group.
MsgCloseGroupCloses a group within a deployment.
MsgUpdateParamsGovernance-only update of module parameters.
QueryPurpose
Deployment / DeploymentsA single deployment, or the deployment list.
GroupA single deployment group.
ParamsCurrent module parameters.
ModuleHow they interact
x/marketDeployment groups generate the orders the market opens for bidding.
x/escrowA deployment funds the escrow that backs its resulting leases.
x/certTenant certificates authenticate the deployment owner to providers.
x/veidDeployment creation is gated by the tenant’s verified identity.

A subdivision of a deployment that becomes an independently-biddable order with its own placement rules — the unit providers actually compete for.

The stack definition language: how services, resources, and placement are described for the marketplace. Think of it as the desired-state document the exchange acts on.

How is the deployment owner authenticated?

Section titled “How is the deployment owner authenticated?”

Tenant certificates (x/cert) authenticate the owner to providers when delivering manifests, and deployment creation itself is gated by the tenant’s VEID identity. See the x/cert module.