Self-Hosted Suna (Kortix): Open-Source AI Operating System for Agents

You have probably seen the pitch by now: an AI that does not just answer questions but finishes the deck, opens the pull request, and nudges Slack when it is stuck. The catch is that most of those products live inside a model lab's cloud, on that lab's models, with your company playbook stored where their lawyers are comfortable.

Suna on GitHub is the open-source project behind Kortix (kortix.com). Same codebase, new name. Roughly twenty thousand stars and a clear positioning: an AI operating system you can run yourself. Agents, skills, memory, connectors, and triggers are files in a git repo you own. Each session gets an isolated Linux sandbox on its own branch; work lands on main only through a change request a human merges.

What Kortix is (and what it is not)

Kortix is built for teams that want something closer to Claude Cowork or ChatGPT Work, except auditable, forkable, and hostable on your own metal. You can use the web app, Slack, Microsoft Teams, or the CLI. Agents run on real cloud computers, not just a chat thread, and they are meant to return finished artifacts: reports, code, replies, scheduled digests.

The mental model is a company as a repository:

  • Agents are OpenCode-style roles (markdown configs) with scoped access to tools.
  • Skills are reusable know-how shared across sessions.
  • Memory is plain files today (a growing company brain, not a black-box vector store only).
  • Connectors reach thousands of apps via brokered credentials (MCP, OpenAPI, GraphQL, HTTP) so raw API keys do not get copied into the sandbox.
  • Triggers fire sessions on cron or signed webhooks when nobody is at the keyboard.

It is not a visual Zapier clone. If you need the same fixed steps every Tuesday, n8n still wins. If you only want chat over PDFs, Open WebUI or Onyx is simpler. Kortix shines when the job is open-ended work with governance: allow, ask, or block per tool call, audit trails, SAML/SCIM on managed tiers, and merge that is deny-by-default for agents.

Why self-host instead of another AI workspace SaaS

Configuration is yours. Agents and policies live in git. You can diff them, review them in PRs, and roll back a bad prompt the same way you roll back code.

Models are yours. Bring Anthropic, OpenAI, a local endpoint, or mix providers with your own API keys. You are not locked to one vendor's model menu.

Sandboxes contain the blast radius. Each session is disposable. The agent can install packages and break things inside its branch; only committed changes survive, and you approve what merges.

Canadian hosting story. For privacy reviews that ask where agent sessions, logs, and connector traffic live, "our VPS in Beauharnois or Toronto, keys in our vault, git on our GitHub org" beats routing every action through a US multi-tenant agent cloud.

Honest caveats. Self-hosting is real software: Docker Compose, integration credentials for git and connectors, and images pulled from Docker Hub on first setup. This is not air-gapped offline mode. Plan capacity for web, API, and sandbox workloads, not a single shared hosting account.

Getting it running

The upstream quickstart is CLI-first:

curl -fsSL https://kortix.com/install | bash
kortix init          # scaffolds kortix.yaml, agents, skills
kortix ship          # managed cloud path

# On your own box:
kortix self-host start
kortix hosts use selfhost

self-host start brings up a production-style stack from published Docker images and generates local URLs, ports, and keys. You still wire the integrations that matter to you (managed git, GitHub, Pipedream-style connectors). Switch back to Kortix Cloud with kortix hosts use cloud if you want to compare before you commit hardware.

Developers hacking on the monorepo use pnpm dev (web + API) and pnpm dev:sandbox for the local sandbox image. Everything ships under one version tag across API, web, CLI, and desktop.

What to budget on a server

Kortix is heavier than a single-container chat UI. Expect at least a modest VPS or dedicated box with enough RAM for Docker (control plane plus occasional parallel sandboxes), fast disk for images and git checkouts, and outbound HTTPS for model APIs unless you run inference locally too.

Put TLS and authentication in front of the web UI. Treat agent sandboxes like production compute: firewall egress if you care about data exfiltration, rotate secrets, and turn on approval gates before you give an agent CRM or ticket-system access. Isolation mode depends on provider (containers vs microVMs on higher tiers).

Who should look at Suna / Kortix

Good fit: platform or IT teams piloting governed agents for engineering, support triage, or scheduled ops digests; shops comparing Cowork-style products who need open source and self-host; orgs already living in Slack/Teams who want @-mention agents with real tool access.

Skip or wait: solo users who only need local chat; teams without appetite to run Docker and review agent diffs; anyone expecting a five-minute install with zero integration setup.

Bottom line

Suna (Kortix) is one of the few open-source bets that treats agents like infrastructure: versioned config, isolated sessions, human merge gates, and finished work instead of endless chat. Self-hosting it on Canadian VPS infrastructure is how you keep that loop under your own security and data-residency story.

Need help sizing a host for Kortix sandboxes and locking the stack behind HTTPS? Talk with Swift Host. We will map Docker resources, egress, and where your model API calls should leave the network.

Tags:
  • Suna
  • Kortix
  • AI Agents
  • Docker
  • Self-Hosted

Need Help With Your Hosting?

Tell us about your application — we respond within 1 hour with honest recommendations.