Deployment

A flow project — your flows and the script code that runs inside them — starts life on your machine. Deployment is how that project reaches the running platform. You build the project and deploy it into a space using that space's deployment token; the platform checks the project, and once it passes, the running system picks it up automatically. There is no restart to schedule and no manual switch to flip — a deployed change goes live within moments.

Deployment is scoped to a space. The space's ID doubles as its project ID, and the deploy tool (keen-builder) authenticates into that space with the deployment token, so a deploy always lands in exactly one space and can only touch the flows that belong to it.

1. Build. You assemble the project locally — its flows and their script code — into the form the deploy tool sends. (The agents themselves live in the admin console and point at a flow in the project you deploy.)
2. Deploy. keen-builder uploads the project into the target space, authenticated by the space's deployment token. A wrong or retired token is refused, so only someone holding the current token can deploy.
3. Security scan. Before anything can run, the platform scans the project for unsafe code. A project that fails the scan is rejected and never goes live — this is the gate that lets partner-authored code be trusted at run time.
4. Go live. Once the scan passes, the project is promoted and the running system picks it up on its own. The new version supersedes the previous one; in-flight conversations finish on what they started, and new runs use the new version.

Deployment token

The credential the deploy tool uses to authenticate a deploy into a space. It is generated for you when the space is created, shown read-only on the space's detail page (with a Copy button), and can be re-minted with Reset Token. Re-minting invalidates the previous token immediately — any pipeline still holding the old value stops being able to deploy on its next attempt.

Security scan

Every deploy is scanned before it is allowed to run. The scan is what makes it safe to run your script nodes on the platform: code that does not pass is never promoted, so a rejected deploy leaves the previously running version exactly as it was.

Supersession

A deploy replaces the space's previous project version — there is one live version per space at a time. Re-deploying is the normal way to ship a change; you do not manage versions by hand.

Space = project

The space ID is the project ID. It is what keen-builder deploys against and what chat clients pass as the project identifier at run time, so the same identifier ties your deploy, your agents, and the caller together.

• Keep the deployment token secret and rotate it if it may have leaked — Reset Token cuts off the old value on the spot. Distribute the new token to your pipeline right away, or the next deploy fails.
• A deploy that is rejected by the security scan does not affect the running agent — the live version keeps serving until a clean deploy replaces it.
• Deleting a space removes its deployed project along with its agents and their settings — one action clears the whole unit, and there is no undo.
• A newly deployed change is picked up automatically within moments; you do not need to restart anything or take the space out of service to ship.
• After the first deploy, saving your project re-deploys it automatically — your edits keep flowing to the space as you build, and each one is scanned before it can run.