Skip to main content

Deploy to sandbox

Drafts are great for iteration but they're throwaway. To run a workflow somewhere stable — for QA, integration testing, or a live demo — you deploy it. Deploys create permanent, immutable, versioned snapshots.

In this tutorial we'll go to sandbox before prod. That's the recommended pattern: shake out integration issues somewhere with no production blast radius first.

Run the deploy​

In your tutorial directory:

culvii deploy vendor-screen.ts --env sandbox --workspace tutorial

The CLI:

  • Compiles your TypeScript to a workflow definition.
  • Validates it against the platform's schema.
  • Checks that you have permission to write to the tutorial workspace in sandbox.
  • Creates a new permanent version (your first one, so v1).

You'll see something like:

✓ Compiled vendor-screen.ts
✓ Validated workflow definition
✓ Workspace exists: tutorial
✓ Published vendor-screen v1 to sandbox

View in Console: https://console.culvii.com/sandbox/tutorial/workflows/vendor-screen

If the tutorial workspace doesn't exist yet in sandbox, the CLI will tell you and ask whether to create it. Confirm with y.

What just happened​

You went from Draft in dev (ephemeral, only you can see it) to Published v1 in sandbox (permanent, your team can see it, recorded in the audit log).

A Published version is not yet Live — it can be run manually but its triggers (cron schedules, webhooks) are not armed yet. That separation is deliberate: deploying and activating are two separate operator actions. For a workflow with no triggers (like this one), the distinction doesn't matter much; it'll matter for production workflows.

See Workflow lifecycle for the full state model.

Run it manually in sandbox​

Open the Console URL the CLI printed. You're now on the sandbox view of your vendor-screen workflow. The version dropdown shows v1.

Click Run, give it { "vendorId": "V001" }, and click Run again.

The trace view looks the same as it did in dev. The difference is that this run is recorded permanently — it shows up in the audit log, it has a stable run ID, and any teammate with access to the tutorial workspace in sandbox can see it.

Iterate by re-deploying​

Make another change to your code — say, change the agent's goal to also include the rating as a percentage in its reasoning. Save it.

Re-deploy:

culvii deploy vendor-screen.ts --env sandbox --workspace tutorial

You'll see:

✓ Published vendor-screen v2 to sandbox

Now the Console's version dropdown shows both v1 and v2. Both are immutable. Both can be run independently. Neither is Live yet.

This is the model: deploy creates versions; activation (covered in Promote to production) decides which version is the version that responds to triggers.

A quick note on sandbox vs prod​

The sandbox environment is fully isolated from prod. Deploying to sandbox does not affect prod. They have separate databases, separate workspaces, and separate API keys. See Tenancy and Workspaces.

When you're ready, the next step takes the same workflow to production: Promote to production.