# Self-host an open-source CompanyOS, and keep the memory > A self-hosted CompanyOS runs the agents, the memory and the connector broker inside your own network, so the record survives a change of model vendor. Kortix is the open-source CompanyOS: your agents, their skills, your company memory, and every connector in one git repo you own, with the agents working on real cloud computers. URL: https://companyosguide.com/self-hosted-company-os ## Three commands to install, one path to review a change The install on a host you name, and the merge that lands a session's work in your own repository. ### self-host `self-host` ```sh $ curl -fsSL https://kortix.com/install | bash $ kortix self-host init --domain kortix.example.com $ kortix self-host start ``` Source: kortix.com/docs/host ### review `change request` ```sh kortix cr ls # open change requests kortix cr diff 1 # the unified diff kortix cr merge 1 # merge into the base branch ``` Source: kortix.com/docs/developers ## What self-hosting has to mean A CompanyOS is four things that have to travel together: the agents and the skills they follow, the memory they read, the broker that holds connector credentials, and the model doing the thinking. Host the dashboard and leave the other three with the vendor, and the company has bought a screen with a login page. Self-hosting moves all four. On [Kortix](https://kortix.com) that means two things a reviewer can point at: the images, started on your own host by `kortix self-host start`, and a git repo holding the agents, the skills, the memory and the connector settings. The images are ordinary software and can be rebuilt from the project's source. The repo is the company, and it is the part you cannot buy back once it lives somewhere else. ## Three shapes, and what changes in each Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free. Who holds the machine is the first difference. On Kortix Cloud the stack runs on Kortix infrastructure. The repo stays yours and clones like any other. In your VPC it runs in an account your security team already audits, with your own network rules and logging in front of it. On-prem it runs on a machine in your building. The certificate for the domain is obtained there, by the `Caddyfile` that `init` wrote. One limit belongs in the plan, not in a footnote. The install pulls its images from docker.io, and sessions run on remote sandboxes by default. A company whose constraint is that no packet leaves the estate needs a topology conversation first. The default install does not answer that on its own. ## Any model, your own keys Any model provider with your own keys. Or the ChatGPT plan you already pay for. Read that sentence beside the memory and it stops being a feature. A model is a reader of the company's files. The party that owns the files should choose the reader. Providers retire models and rewrite their terms. The change here is a key and a setting, in a project you already hold. Move a memory that lives in a tenant, and the same change becomes a migration. It is scoped and scheduled by the party you are leaving. The record a company's agents build outlives the model vendor only when the record is a repository. A repository clones. A vendor-risk form asks whether the company could leave. The answer is a clone of the repo, taken whenever you like. ## What you still operate Self-hosting leaves the operator a short list of jobs, and each one is small enough to name. - Upgrades. `kortix self-host init` writes `docker-compose.yml`, `.env`, a `Caddyfile` and `updater.sh` into `~/.config/kortix/self-host//`. That folder is the control surface, and the updater is a script you can schedule yourself. - Model keys. They are entered in the app, per project, and belong to the company's own billing relationship with the provider. - Connector accounts. Each connector still holds an account with the app it reaches, and that grant is revoked where it was given. - Certificates. The `Caddyfile` obtains and renews TLS for the domain passed to `init`, so the host needs port 80 and 443 reachable. Plan the first install for a host that already has Docker and the Compose plugin. After that the operator's job is four files, one script, and the keys. ## Where the knowledge-layer products stop Three products sold under the name share one limit: none of them leaves you a host to own. At companyos.cc, the shared facts, procedures and templates sit inside the Claude, ChatGPT or Codex account each person already opens. The AI reads those files and the connected tools, and it writes to neither. What the product supplies is shared knowledge, and there is no stack to run. company-os.ai hands over a free, open-source template and a local Office app: start the app with `python3 companyos.py serve` on a machine of your own, and you and your agents keep goals, decisions, services and money in one Office. It starts no agent session and hosts nothing for the team, so installing it answers a question about your laptop rather than about a host you own. companyos.com is an operational platform for manufacturers and distributors, and the vendor runs it as a managed pilot. Its agents carry out defined tasks in connected systems, inside the access the customer approves. For a factory with an ERP and no platform team, that is sensible. A company that has to hold the instance is asking for something else. Each of the three suits a buyer who wants the knowledge layer alone. A buyer with a residency constraint and a repository to keep needs the fourth, which is the only arrangement that leaves both in the company's hands. ## The memory is a repo, not a tenant A repository has history. Every decided procedure, every rewritten skill and every correction to the company memory arrives as a diff, with a name and a date on it. A bad edit rolls back with one revert. An export from a tenant is a copy somebody else chose the shape of. The exit is the interesting part, because it happens at the worst time. A repo is cloned in a minute by anyone who already has access. The agents read it on the other side without a translator, because the files are markdown and a YAML manifest. Nothing in the arrangement requires the new host to be the old vendor's product. Where the work runs is a separate question from where the record lives. A repo moves to a new host with one clone, and the machines that ran the sessions stay behind on the old estate. The install order and the tunnel option for a laptop test are in [Read the docs](https://kortix.com/docs/developers). [The checklist page](/what-a-company-os-must-contain) names the parts a candidate has to ship. [The teams page](/companyos-for-teams) covers the first month with several people in one repo. ## Questions a residency review asks The four that come up first, answered in a sentence or two. ### Can a CompanyOS run fully on-premises? Yes. Kortix runs on Kortix Cloud, in your VPC, or on your own on-prem network, and self-host is free. Two things still reach the network: the install pulls images from docker.io, and sessions run on remote sandboxes by default. ### Which models can a self-hosted CompanyOS use? Any model provider with your own keys. Or the ChatGPT plan you already pay for. The key is the company's, so a provider change is a setting in the project rather than a migration of the memory. ### Who owns the data a CompanyOS collects? The company that runs the instance. Agents, skills, memory and connector settings sit in a git repo it hosts, so the record travels with the company rather than with a vendor. ### Is self-hosting free? Yes. Self-host is free. You pay for the host, the network and whichever model provider you use, and the software itself carries no fee from Kortix. ## Install it on a host you can point at. Three commands, one repo, and a reviewer who can read every file before the first session runs. [Try Kortix](https://kortix.com) ยท [The parts to check](https://companyosguide.com/what-a-company-os-must-contain)