One person babysitting three ChatGPT tabs is not an operating model. The model can run all day; your attention cannot. Schedules, webhooks, and Slack threads still need something that wakes up, does the work on an isolated machine, and stops asking you to paste the same CRM export again.
Kortix CompanyOS is the open-source repo Kortix ships today (roughly 20k GitHub stars, TypeScript monorepo, default branch dev). We wrote about the earlier Suna tree last year; CompanyOS is the same idea with a clearer name: a company operating system where agents, skills, connectors, and rules live in git, sessions run on disposable cloud computers, and humans approve what merges to main.
What makes it a CompanyOS, not another chatbot
Kortix draws an explicit analogy to a real OS. My Kortix is the shell: you talk to one agent, it routes research, code, and writing to specialized pi agents without blocking the conversation. Agents are the programs (custom prompts, models, permissions). Skills are shared libraries. Drive holds company memory as Markdown. Connectors reach 3,000+ apps plus MCP, OpenAPI, and raw HTTP with credentials kept off the sandbox. Triggers are the scheduler: cron, signed webhooks, connector events, change requests.
Where it goes past single-session copilots:
- Always on, not always burning CPU. Each session gets its own computer; it sleeps 15–20 minutes after the last turn and wakes with full history when the next event hits.
- Swarms. Background hand-offs, workflows across many agents, and messages between sessions so thousands of jobs can run in parallel on one config.
- Long horizon. When context fills, the agent continues in a fresh window and searches the session record verbatim instead of trusting a vague summary.
- Outcomes. You state a goal once; an agent plans, works, and a separate verifier session checks done-before-merge; learnings feed back into skills and memory.
- Apps. Agents can build and host internal sites and backends at stable URLs, with releases and rollback, not only throwaway chat output.
Everything is declared in kortix.yaml and plain files in a repo you own. That is the "company as code" pitch, and it is why privacy reviewers ask whether you can host the control plane yourself.
Who is actually running this?
Kortix publishes case studies rather than anonymous logo walls. Examples from their README: SciencePal at City University of Hong Kong's AI for Science institute; Platinum (sandbox infrastructure built by agents on Kortix); Kortix's own issue triage and fix bots; a telecom shop self-hosting agents that design fiber routes; WRITER and other enterprise builds on the open-source base. The pattern is teams that already treat automation as software engineering, not magic buttons.
If you only need RAG over PDFs, Open WebUI or Onyx is lighter. If every Tuesday is the same five steps, n8n still wins. CompanyOS is for governed, open-ended agent work with multiplayer access (web, desktop, mobile, CLI, Slack, Teams, email, MCP).
Why self-host?
Sovereignty. Open source you can fork and audit; stack in your VPC, on-prem, or Kortix Cloud from the same Docker images. Model keys stay yours; an LLM gateway enforces budgets and access rules.
Multiplayer without siloed chats. Roles, groups, per-resource permissions, SAML SSO, SCIM, audit logs, and change requests before agent edits land on main.
Blast radius. Sandboxes are disposable; connector secrets never enter the session filesystem. Merge is deny-by-default for agents until a person approves.
Canadian hosting angle. When a client asks where agent sessions, logs, and connector traffic live, "our VPS in Beauharnois or Toronto, git in our org, keys in our vault" beats routing every action through a US multi-tenant agent cloud you cannot inspect.
Reality check. Self-host pulls images from Docker Hub, wires GitHub and model providers, and configures a sandbox provider (Platinum by default). This is not air-gapped. Budget RAM and disk for the control plane plus parallel sandboxes, not a shared cPanel account.
Getting it running
CLI quickstart:
curl -fsSL https://kortix.com/install | bash
kortix init
kortix ship # managed cloud
kortix self-host start # Docker Compose on your box
kortix hosts use selfhostFirst self-host run asks a handful of setup questions (no model key required upfront). Connect GitHub and add provider keys in the app afterward. Hackers on the monorepo use pnpm dev (web + API) and pnpm dev:sandbox for local sandbox images. API, web, CLI, and desktop release together under one version tag.
Put TLS and auth in front of the web UI. Firewall sandbox egress if you care about exfiltration. Turn on approval gates before you give an agent CRM or ticket-system write access.
Who should look at CompanyOS
Good fit: platform or IT teams piloting governed agents for engineering, support triage, scheduled digests, or internal app generation; orgs comparing Cowork-style products who need open source and a merge gate; shops already in Slack or Teams who want @-mention agents with real tool access.
Skip or wait: solo users who only want local chat; teams with no appetite for Docker, git-reviewed agent configs, or integration wiring; anyone expecting a five-minute install with zero follow-up setup.
Hosting it in Canada
CompanyOS belongs on a properly sized CloudBox VPS or dedicated box: fast disk for images and git checkouts, enough RAM for Docker, outbound HTTPS for model APIs unless you run inference locally too. Beauharnois or Toronto keeps the control plane and session metadata under your residency story while you still choose which model providers see prompt content.
Need help sizing sandboxes, egress rules, and TLS in front of the stack? Talk with Swift Host. We are in St. Albert and actually answer the phone.
