Your first deploy

Deploying to Vadyl is one command in the simple case and a full approval-gated rollout in the rigorous case. Same canonical lifecycle, different opt-in depth.

The simple deploy

vadyl deploy

On a fresh project with no protection policies, this:

1. Bundles your source assets and computes a content hash.
2. Builds a runtime artifact for each authoring language unit.
3. Runs schema diff against the current production schema.
4. Classifies the migration (metadata-only, instant, native online, expand+backfill, blocking, destructive).
5. Applies safe migrations automatically; prompts for approval on risky ones.
6. Reserves a new ProjectRuntimePublication version.
7. Switches traffic atomically once the new version is healthy.

Branches, sandboxes, proposals

These are different units of evolution and they compose:

• Branch — a named lineage of canonical state. Like a git branch, but for your product model. Has its own commit history.
• Workspace — your in-progress overlay on a branch. Optimistic concurrency, actor-owned.
• Sandbox — an isolated database (and runtime) provisioned for testing risky changes against real data. Lives until you destroy it.
• Proposal — a typed pull-request analog. Carries a diff between two branches, supports approvals, validation gates, and policies.
• Deployment — the explicit intent to apply a branch to an environment. Runs through DDL, runtime publication, and progressive rollout.

Preview before applying

vadyl deploy preview --target production

Shows you the planned schema changes (with classification + reasoning), the new artifact bundles, the publication version that will be reserved, and any policy violations. Nothing is applied. The output is the same canonical projection a proposal review would surface in the dashboard.

Approval flow

Add a protection policy to your branch in vadyl.config.ts:

branches: {
  main: {
    protection: {
      requireValidation:    true,
      requiredApprovalCount: 2,
      restrictDirectCommit: true,
    },
  },
},

Now any merge into main requires the validation pipeline to pass and two explicit approvals. Approvals are signed by canonical actor identity, audit-trailed, and replayable.

Promote with a ramp policy

vadyl deploy --target production --ramp 5%,25%,50%,100% --bake 10m

Vadyl progressively shifts traffic through each ramp step, baking for the specified duration between steps. Health checks gate each step: if error rate, latency, or operational-trail anomaly thresholds are exceeded, the rollout pauses automatically. You can resume, hold, or roll back from the dashboard or CLI.

Rolling back

vadyl deploy rollback --target production --to v412

Switches the runtime publication pointer back to a prior version and reverses any reversible DDL. For irreversible DDL (destructive column drops, etc.), Vadyl tells you exactly what cannot be reversed and what compensating action is needed.

What you'll see in production

Every deployment produces an audit trail you can replay through the explainability plane. Operational trails on the deployment, the per-step DDL classification, the artifact signatures, and the actor identity that approved each step are all canonical and queryable.