Suna

Suna is an open-source AI command center that lets you run a workforce of autonomous agents as code you own. Instead of a chat box, you get a full platform: agents defined in Markdown, skills that encode company know-how, triggers on cron or webhooks, connectors to 3,000+ apps, and encrypted secrets — all living in a single git repository that represents your company as versioned, diffable text.

Each session boots a disposable Linux sandbox on its own branch via Daytona. The OpenCode runtime inside the sandbox reads your kortix.toml and agent configs, does the work, commits it, and opens a change request you approve before anything reaches main. You can run hundreds of these sessions in parallel — they’re fully isolated, fed by the same config, and they feed work back through pull requests so the company improves one reviewed change at a time.

The self-host story is straightforward: pull the Docker images, run kortix self-host start, and switch the CLI between Cloud and your own infrastructure. Secrets are managed via dotenvx encryption — committed as ciphertext, decrypted at runtime, never exposed to the model. Elastic License 2.0 means you can self-host freely but cannot offer Suna as a managed service to others.

Suna is built for founders, engineers, and ops teams who want AI to do real work — not generate more chat — and who insist on owning the configuration, the data, and the model choice. It integrates with any LLM provider, supports BYOK, and works with the ChatGPT, Claude, or Cursor subscription you already pay for.

What You Get

• Git-backed company config — Your entire operation lives in kortix.toml and Markdown agent files, fully versioned and diffable so you can grep your whole company and roll back any change.
• Isolated session sandboxes — Each session boots a fresh Linux sandbox on its own branch via Daytona; agents install, run, and break things freely, and only committed work survives.
• Change-request workflow — Agents push their output as pull requests against main; no work lands without a human approval gate, so the system self-improves in a controlled, auditable way.
• 3,000+ connectors in one click — Pipedream, MCP, OpenAPI, GraphQL, and raw HTTP integrations are brokered server-side through a single scoped token so sandboxes never hold raw credentials.
• Cron and webhook triggers — Schedule sessions to fire every morning or on any signed HTTP event, Git event, or Slack message — all declared as [[triggers]] in kortix.toml.
• Multi-channel agent access — Stand up bots on Slack, Teams, Discord, Telegram, or mobile with one click; agents start sessions and stream back work from wherever your team already works.
• Parallel workforce — Run hundreds of agents simultaneously on the same config, each fully isolated, each feeding finished deliverables back through change requests without colliding.
• Bring-your-own models — Connect any LLM provider with your own keys, or use the Claude, ChatGPT, or Cursor subscription you already pay for; no model lock-in.

Common Use Cases

• Automated PR review bot — A PR-bot agent triggers on GitHub pull_request webhooks, checks out the diff, runs the thermonuclear-review skill, posts a sticky comment, and opens a stacked fix PR — all without human involvement.
• Nightly engineering digest — A cron trigger fires at 09:00 Monday–Friday, the agent summarizes yesterday’s commits across the mono-repo, saves the result to notes/digest-<date>.md, and opens a PR so the team reviews it with their morning coffee.
• Parallel outbound research — Fifty sessions run the same research agent on fifty target companies simultaneously, each isolated, each committing a structured report file; a rollup agent merges the results into a single deliverable.
• Self-healing deployment pipeline — A webhook trigger fires on CI failure; the agent checks out the branch, reads the build log, applies the fix-ci skill, patches the offending file, and opens a change request with the fix — reducing MTTR without paging an engineer.
• Customer support triage — A Slack channel bot starts a session on every customer mention, searches the knowledge-base skill, drafts a reply, and posts it for a human to approve before sending — cutting response time while keeping quality control.

Under The Hood

Architecture Suna is a monorepo organized around a clear boundary between the cloud platform and the sandboxed agent runtime. The API layer (Hono.js, Bun, OpenAPI/Zod) acts as the command-and-control plane: it provisions Daytona sandboxes, manages session lifecycle through an explicit state machine with durable lease-based workers, routes LLM calls through a provider-agnostic gateway backed by OpenRouter, and brokered third-party calls through a policy-enforcing executor that injects secrets server-side. The agent runtime inside each sandbox runs OpenCode, reads the project’s kortix.toml and Markdown agent configs, does the work on an isolated git branch, and communicates back to the API via an SSE event stream proxied through the platform. Change requests bridge the agent’s ephemeral branch back to main through a human approval gate, making the architecture self-improving and fully auditable by design.

Tech Stack The API is written in TypeScript on Bun with Hono.js as the HTTP framework, Drizzle ORM over PostgreSQL for structured persistence, and Supabase for authentication and realtime. Sandboxes are provisioned through the Daytona SDK and managed as microVMs with a repo-clone-on-boot workflow. The LLM gateway routes to any provider via OpenRouter and also accepts direct Anthropic calls. The web dashboard is Next.js 15 with Sentry observability, dotenvx-encrypted environment files committed to git, and three environment profiles (local, dev, prod) with the production stack loading secrets from AWS Secrets Manager at runtime. The CLI is a Bun-bundled TypeScript binary. Infrastructure is defined as Docker Compose with environment-aware profiles and a custom sandbox Docker image (kortix/kortix-sandbox) built from the repo.

Code Quality The test surface is extensive and well-structured: dozens of unit tests cover individual modules (executor, auth, billing, IAM, Slack, Stripe, tunnels, leader election) and a growing black-box e2e suite (ke2e) hits a live API with real Daytona sandboxes and real Supabase, asserting against a coverage gate derived from an auto-generated 328-route manifest. Bun:test is used throughout. Error handling is explicit and typed — Hono’s HTTPException, a custom BillingError, and Sentry breadcrumbs at key decision points. Secrets are enforced at commit time via a pre-commit hook and GitHub push protection. The codebase uses consistent domain-driven naming, Zod schemas at API boundaries, and OpenTelemetry spans for observability.

What Makes It Unique Suna’s defining technical bet is that a company’s operational configuration belongs in git alongside its code — not in a SaaS dashboard. The result is a platform where the entire workforce of agents, skills, triggers, and connectors is grep-able, diff-able, and rollback-able like any other codebase. The change-request workflow — where agents can only reach main through a pull request you approve — makes AI-driven self-modification safe enough to run autonomously, which is a genuine engineering solution to the alignment-in-production problem that most agent platforms sidestep. Running hundreds of identical, fully isolated sessions in parallel on the same config without shared mutable state is the other architectural choice that separates Suna from single-agent tools.

Self-Hosting

Suna is released under the Elastic License 2.0 (ELv2). In plain language this means you can use, copy, modify, and self-host the software freely — including commercially — as long as you do not offer it to third parties as a hosted or managed service where access to a substantial part of Suna’s functionality is the product itself. If you are running Suna to power your own company’s agents, you are squarely within the license. If you are building a service that sells Suna-powered agent capacity to others, you need a commercial agreement with Kortix.

Running Suna yourself is a real operational commitment. The local stack requires Docker (for Supabase and the sandbox image), Bun, Node, and pnpm, and the full dev environment consumes 6 vCPUs and 12 GiB of RAM per sandbox template. Production-style self-hosting means managing a PostgreSQL instance, a Supabase stack, a Daytona account for sandbox provisioning, and an AWS Secrets Manager (or equivalent) for runtime secrets. The dotenvx-encrypted .env files committed to the repo simplify secret rotation across environments, but key management (Dotenv Armor) is an additional dependency. You are responsible for uptime, database backups, sandbox pool capacity, and version upgrades — all of which require meaningful DevOps investment.

Kortix Cloud (kortix.com) provides the managed alternative: sandboxes, database, auth, secrets, and the CLI-to-cloud handshake are all handled for you with a kortix ship command. The Cloud tier adds managed git hosting, GitHub OAuth integration, Pipedream connector brokering, and enterprise features like microVM isolation, SCIM provisioning, per-resource permissions for agents, a full audit trail, and human approval gates on sensitive actions. Support, SLAs, and high-availability database replication are available on enterprise plans but not in the self-hosted community version.