> ## Documentation Index > Fetch the complete documentation index at: https://docs.karta.sh/llms.txt > Use this file to discover all available pages before exploring further. # The deploy loop > Ship, serve, consume: publish an agent, get a stable agent path, and route sessions into durable kartas. Deploy your agent - from the dashboard, a folder upload, a `git push`, or your CI - and the result is a **stable agent endpoint** something can talk to, at `agent.karta.sh//`. Each session through that endpoint resolves to the right durable karta: one per user, one or more virtual employees, one per backend job, or another id you choose. ``` SHIP SERVE & CONSUME --------------------------------------------- --------------------------- +------------+ karta deploy +--------------------------+ | your agent | --------------------------------> | KARTA | | folder | (git push, folder upload, | version, build, activate | | | the dashboard, or CI) | assign agent path/slug | +------------+ +------------+-------------+ | | exposes v https://agent.karta.sh// +--------------------------+ | session API: | | create, send, stream | +------------+-------------+ | | resolve karta id v +--------------------------+ | durable karta | | workspace, sessions, fs | +--------------------------+ ``` ## What "deploy" means here A deploy does two things: it publishes a new, immutable, versioned [release](/concepts/releases) of your agent - the skills, tools, sub-agents, and context files - and it makes that release available to the durable kartas behind the agent's path. The harness (Claude Code, OpenCode, DeepAgents, Goose, Codex CLI, or another supported runtime) is the runtime inside each isolated run environment; the release is what it loads. "Going live" is pointing the agent's active marker at the new release so the *next* session starts on it. That framing drives the properties you want: Every publish produces `v1`, `v2`, and so on, tied to a commit SHA. The published artifact for a version is never overwritten. Going live is a `current_release` pointer flip - so rollback is a flip back. In-flight sessions finish on their release; the next session gets the new one. No forced disconnects, no Karta redeploy. A pull request records its own ephemeral, auto-expiring preview release. The package is the harness's own layout; the only Karta-specific file is an optional `karta.toml` for build hints. The first publish assigns a durable slug. New releases change the code behind `agent.karta.sh//` - never the slug. ## Choose a deploy mode | Mode | Command | Use when | What ships | | -------------- | -------------------------------------------------------------- | ----------------------------------------------------------- | ----------------------------------------------------------------------- | | Git push | `karta deploy` from a git repo, then `git push karta main` | You want committed releases and a hosted source remote. | The committed `HEAD`; uncommitted changes must be committed or stashed. | | Folder upload | `karta deploy --mode folder` | You want to ship a folder without depending on git history. | The current working tree, honoring `.gitignore`. | | GitHub Actions | `karta setup --method github`, then push to your deploy branch | You want CI to deploy every push. | The workflow runs `karta deploy --mode folder` with `KARTA_API_KEY`. | In a multi-agent repo, Karta builds each folder whose `karta.toml` has `deploy = true`. ## The end-to-end loop Author and test the agent in your own repo, harness, model setup, and evaluation loop. Use [`karta dev`](/cli/overview) when you want to exercise the same session API and approval surface Karta serves in production. Run `karta deploy` - on first run it provisions the agent, assigns its slug, and wires the `karta` git remote; thereafter `git push karta main` is the transparent equivalent. Build progress streams back in the output. A plain folder uploads instead of pushing. If the repo holds [multiple agents](/build/agent-structure#multiple-agents-in-one-repo), one deploy builds every agent whose `karta.toml` sets `deploy = true`, each from its own subdirectory. See the [CI example](/deploy/releases-and-rollback#deploy-from-ci). Karta allocates the next version and materializes the artifact, building it from your [`karta.toml`](/build/karta-toml) - a Dockerfile, a buildpack runtime, or the file tree run directly - without translating the project out of the harness's native format. On a successful production build, Karta flips `current_release` atomically and records an audit event. A PR build becomes a time-boxed preview instead. The agent path speaks the [session API](/api-reference/sessions) - create a session, send, stream. The caller supplies or derives the karta id, Karta resumes that durable workspace, attaches an isolated runtime for the turn, and streams the harness events back through the same agent UX. Flip `current_release` back to a prior release; the next session reverts. The path is unaffected. See [Releases & rollback](/deploy/releases-and-rollback). ## Why a fixed session protocol A web app exposes whatever routes its developer invents; every Karta agent exposes the **same** session protocol. That's deliberate - a fixed API is why *one* chat widget can talk to *any* Karta agent, and why a hosted agent and a local harness session are interchangeable from a client's point of view. What an agent ships is *agent behavior*, not custom endpoints.