Deploy with branching

Vadyl deploys are not push-and-pray. They follow the canonical branching lifecycle — workspace, commit, sandbox, proposal, deployment — with explicit gates at every step. You can move slowly and rigorously, or quickly and casually; the same machinery powers both.

The canonical flow

1. Branch a feature off main.
2. Commit changes to your workspace.
3. (Optional) Sandbox a real database to test the changes.
4. Propose the change as a typed proposal against main.
5. Wait for validation and approvals.
6. Merge when policies pass.
7. Deploy the new commit to an environment.
8. Watch the ramp progress; intervene if needed.
9. If something is wrong, roll back to a prior publication.

Workspaces vs sandboxes

A workspace is your in-progress overlay on a branch — optimistic concurrency, your edits, your tests. A sandbox is an isolated database (and runtime) provisioned for the workspace, so you can run risky migrations and backfills against a real DB without touching production.

vadyl branch create feature/new-pricing
vadyl sandbox create --branch feature/new-pricing --seed snapshot:prod-latest
vadyl deploy --target sandbox:feature/new-pricing
# poke around, run tests, validate the migration
vadyl sandbox destroy --branch feature/new-pricing

Preview before applying

vadyl deploy preview --target production

Output includes:

• Planned schema changes with classification and reason codes.
• Bundled authored artifacts and their content hashes.
• Runtime Fabric changes: surface scaling policy, resource policy, ingress, load balancing, and substrate capability satisfaction.
• Reserved publication version.
• Policy violations (if any) blocking the deploy.
• Reversibility analysis per migration step.

Approval gates

Branch protection policies enforce who can push what:

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

Approvals are signed by canonical actor identity, audit-trailed, replayable. The dashboard shows reviewer comments alongside the typed diff.

Promotion with ramp

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

Vadyl shifts traffic through each ramp step, baking for the specified duration between steps. Health gates evaluate operational trail anomaly thresholds (error rate, latency p50/p99, exception count). On threshold breach, the rollout pauses automatically.

Runtime scaling policy

vadyl runtime-fabric scaling preview --project billing --file runtime-topology.json
vadyl runtime-fabric scaling set-policy --project billing --surface CoreHandler --file core-autoscale.json
vadyl runtime-fabric scaling set-resources --project billing --surface EventConsumer --cpu 1000 --memory 2048
vadyl runtime-fabric autoscale explain --project billing --env production --surface EventConsumer

Scaling changes are topology changes. They are previewed, capability checked, governance checked, explained, audited, and applied through Runtime Fabric. A surface can be fixed, manually scaled, or autoscaled; it can use its own resource policy and load-balancing intent; and it can be grouped with other surfaces when the topology requires them to scale together.

Rollback

vadyl deploy rollback --target production --to v412

Switches the publication pointer back to v412 and reverses any reversible DDL. For irreversible DDL (column drops, type narrowing that would lose data), Vadyl tells you exactly what cannot be reversed and what compensating action is required (typically a new forward-only deployment with a recovery script).

Recovery from partial state

If a deployment is interrupted (process crash, network partition), the next operator command sees the partial state and offers an explicit recovery action: complete the rollout, abort and roll back, or pin the current state and investigate. There is no "stuck deployment" mystery state.

Auditability

Every deployment produces a deployment record with: the commit applied, the actor who triggered it, the actors who approved it, the ramp policy used, the per-step health metrics, and the operational trail of every DDL execution. Replay it anytime through the explainability plane.