Self-host an open source Perplexity Computer alternative
Self-hosting an open source Perplexity Computer alternative comes down to four decisions and one install. Kortix is the open-source AI Operating System, and it runs as one Docker Compose stack you control on a laptop, a VPS, your VPC or your own on-prem hardware.
Three commands to a running self-hosted instance.
Install the CLI, initialize the instance, then start the stack on a Linux box you control.
$ curl -fsSL https://kortix.com/install | bash$ kortix self-host init --domain kortix.example.com$ kortix self-host start$ kortix self-host configure$ kortix self-host status$ kortix self-host update --tag 0.9.84# kortix.yamlagents: support-triage: file: agents/support-triage.md connectors: alltriggers: - slug: daily-digest type: cronWhat self-hosting buys you
Self-hosting an open source Perplexity Computer alternative runs the whole system on hardware you control, and four things change. Your data and credentials stay on your side: the repo, the memory files and the brokered connector credentials all sit on machines you own. You bring your own model keys, and Kortix is open source, so you can read, fork and audit the code you run. There is no per-seat charge on a self-hosted instance: self-host is free, and you pay for your own compute and model usage. The trade is operational: you own uptime, upgrades and isolation, which means patching the host, watching the Docker Compose stack and backing up the data yourself.
The four decisions
Self-hosting Kortix comes down to four decisions: which project to run, which host to prepare, which models to connect, and which rules to set for agents. The commands for the install and start steps are in the code panels on this page.
1. Pick the project
Perplexity Computer is a hosted, closed product: it runs only in Perplexity's cloud, and its local Portable Computer build runs a runtime you cannot audit (Vellum's breakdown). Self-hosting therefore starts with software that publishes its source, and the pick here is Kortix, the open-source AI Operating System. Kortix self-hosts on a laptop, a VPS, your VPC or on-prem, and one git repo holds the whole system.
Other open source projects run on hardware you control, with narrower scope. OpenClaw is a personal assistant that runs a Gateway on your own computer and answers in the chat channels you already use. Eigent is a cowork desktop with local or self-hosted deployment and a review step before you accept a result. AnythingLLM runs entirely on your device for chat over your own documents. Vellum runs on your Mac or in Vellum's cloud. The alternatives page scores the wider field.
2. Prepare a host
Any machine you control works: a laptop to try it, a VPS for a team, a VPC or an on-prem server for regulated work. Kortix runs as one Docker Compose stack that holds the frontend, the API, the LLM gateway, and the Supabase distribution; agent sessions run on a separate sandbox provider, not on this stack (Kortix self-hosting docs). Three commands take a bare Linux box to a running system: install the CLI, initialize the instance, then start the stack. The first run asks six things and no model key, GitHub connects in the dashboard under Settings → Git, and the stack has no Redis and no separate worker. The instance needs the internet, because kortix self-host start pulls images from docker.io and the sandbox must be able to call back.
3. Connect your models
Give each agent the model it should run on. Any model provider with your own keys. Or the ChatGPT plan you already pay for. Or sign in with your OpenCode Console account for OpenCode Zen and Go. On a self-hosted instance you connect your own LLM key in the model picker, and self-hosted instances use your own key by default. Changing the model later is a config edit in the repo you already own.
4. Harden what agents may touch
Lock the system down before real work runs. Connector credentials are brokered server-side and never enter the machine, and secrets are encrypted at rest with a key per project. Set every tool to allow, ask or block, down to the arguments of a single call. Approval gates you set. Off until you set them. One isolated sandbox per session. Each session has its own isolated machine and branch. Session work reaches main through a change request. Merge is default-deny for agents, so nothing lands without a review.
Where to run it
The same install runs on a laptop, a VPS, your VPC or your own rack, and Kortix Cloud is a fifth option when you want no operations of your own. Pick the host by what you can maintain.
| Host | Good for | You provide | You manage |
|---|---|---|---|
| Laptop | A first trial on your own files | Docker and the install | Backups |
| VPS | A shared instance for a team | A small Linux server | Uptime, upgrades, backups |
| VPC | Work inside your cloud account | Your cloud account | Network rules and keys |
| On-prem | Regulated environments | Your own hardware | Patching, capacity, recovery |
| Kortix Cloud | Starting with nothing to run | Nothing | Nothing |
Why Kortix is the self-hosted pick
Kortix is the self-hosted pick because the whole system is one repo and one command surface. One git repo holds the agents, the skills, the company memory, the connector config and the triggers, so the whole system is text you can read, diff and roll back. The connector surface is 3,000+ apps in a click, plus MCP, OpenAPI, Postman, GraphQL and raw HTTP. Run it on Kortix Cloud, in your VPC, or on your own on-prem network; self-host is free. OpenCode is the harness, and the configuration stays files you own. Read the source at Kortix on GitHub. For a Kortix-against-Perplexity breakdown, read how Kortix compares with Perplexity Computer and the review of Perplexity Computer; for the field-wide view, see the Kortix blog.
Frequently asked questions
- N01
Can I run a self-hosted Kortix instance without a domain?
Yes. Kortix ships an evaluation mode that uses a Cloudflare tunnel instead of a domain: run
kortix self-host init --tunnel cloudflare, thenkortix self-host start. The tunnel URL changes on every restart, so use this mode for evaluation rather than production. - N02
What do I point my domain at for a self-hosted instance?
Create an A/AAAA record for your domain and for
api.<domain>, both pointing at the box's IP, and open ports 80 and 443. The bundled Caddy proxy uses those ports to issue a TLS certificate (Kortix self-hosting docs). - N03
How do updates and backups work on a self-hosted instance?
Every instance updates itself automatically. Pin a version with
kortix self-host update --tag <version>, or turn the updater off with--auto-update off. There is no separate backup system, so back up the Postgres directory, the storage directory and the instance.envbefore a destructive command. - N04
Is self-hosting Kortix free?
Self-host is free. You pay your own compute and model bills, because you bring your own keys. The managed Kortix Cloud has separate paid plans.
- N05
Which sandbox provider should a self-hosted instance use?
Agent sessions run on a provider you choose with
kortix self-host configure, separate from the stack itself. The default is Daytona, and Platinum and E2B are also supported.
Run Kortix on hardware you control.
Start with one job, on one host, with your own keys.
Open source · Any model, your keys · Self-host, VPC, or on-prem