Deploy to your cloud (BYOC)

Deploying an agent activates a released version on the managed runtime. This page explains versioning, what deploy actually does, and how BYOC connects to infrastructure you control.

Versioning and release

Agents are versioned. As you edit an agent in the builder, you're working on a draft. When it behaves the way you want, you release a version — that version becomes the immutable, deployable artifact. You can have an eval suite attached to the release gate so a version can't be released until it passes.

Once a version is released, you deploy (activate) it. You can later release a new version and deploy it on top of the old one, or roll back to a prior version if something regresses.

What "deploy to your cloud" does

"Deploy to your cloud" activates the released version on the managed runtime. Specifically, it:

• Re-enables that version's schedules and triggers, so cron jobs and webhooks start firing against the newly active version.
• Stores a hashed monitoring token for the deployment, used to authenticate the opt-in monitor-agent sidecar if you use it.
• Supports rollback — deploying an earlier version deactivates the current one and reactivates the one you picked.

Be precise about what this is not: deploying does not spin up an untrusted process or container on your infrastructure. The agent still runs on the managed runtime with the sandboxed tool execution described elsewhere in these docs. Deploy is an activation step — it decides which released version is live and wired to its triggers, not where the agent's code executes.

BYOC over SSH

BYOC (bring your own cloud) connects to infrastructure you control over SSH so you can host supporting infrastructure yourself rather than relying solely on the platform's defaults.

Private keys used for this connection are held in memory only for the duration of the deploy operation and are cleared immediately after. They are never written to disk or persisted anywhere on the platform.

Typical flow

1. Iterate on the agent in the builder.
2. Release a version once you're happy with it (and it passes any attached eval suite).
3. Deploy that version — this activates it on the managed runtime and re-enables its schedules and triggers.
4. If a new version misbehaves, roll back to the previous version.

Related

• triggers and schedules — what gets re-enabled on deploy
• execution traces — inspecting runs after deploy