Deployment

Going from a typed project on your machine to governed agents running in production is a push. Connect a repository, and the platform builds and deploys what you defined — versioned, promotable, and on infrastructure you control.

#Overview

You define agents, connectors, skills, actions, and triggers in a single typed project using the open SDKs. Deployment turns that project into running, governed entities on the platform — there is no separate release pipeline to build or CI to wire up.

#Connect a repository

Deployment is Git-native. You connect a Git repository to the platform through the GitHub App, granting it access to the repositories you choose. From then on, the platform watches the default branch.

Every push to the default branch builds and deploys your agents and pipelines automatically. The platform detects your project type from its source contents, so it knows how to package it; you push code, and the platform takes it from there.

Note

Triggers declared in your project ship and version with your code on every deploy. Triggers created in the control plane are preserved across deploys. See Triggers for the distinction.

#Build & versioning

Each push produces a build. The platform packages the project into a versioned image and rolls it out, so every deployment corresponds to a specific, identifiable release rather than a moving target.

  • Automatic builds — a push to the default branch is the trigger; the build runs without manual intervention.
  • Versioned releases — each deployment is a discrete version, so you always know which code is running.
  • Resilient rollout — when pushes arrive in quick succession, the latest one wins and earlier in-flight builds are cancelled.

#Environments

Production is not the only place agents run. The platform supports environment promotion — develop and validate in lower environments, then promote the same versioned release through staging to production. What you tested is what you ship, because it is the same build moving forward.

#Bring your own keys

Every tier ships with bring-your-own-keys (BYOK). You connect your own model providers with your own credentials. The platform does not intermediate model access and does not bill for tokens — your relationship with your model providers stays yours.

This is why the observability layer reports an estimated cost rather than an invoice: the platform gives you visibility into spend without standing between you and your providers.

#Deployment options

Kraken runs where your infrastructure lives. Your agents operate on sensitive business data and take real action, so where that happens is your call.

  • Dedicated cloud instances — the baseline. An isolated instance of the platform, managed for you.
  • Private networking — for teams that need network isolation between the platform and their systems.
  • On-premises & air-gapped — for regulated environments where data cannot leave a specific boundary.

These options are also what let the platform satisfy strict data-residency requirements. See Audit & Compliance for how deployment models map to residency, and Open by Default for the reasoning behind running on your terms.

#Next steps

  • Triggers — How declared triggers ship with your project and what fires a run once it is deployed.
  • Observability — Watch deployed runs live, trace their decisions, and track usage and cost.
  • CLI — The command-line tooling for authenticating, scaffolding, and working against a deployed platform.