Can you self-host a Grok Bot? What open source gives you instead

What has to be true before you call it self-hosted

Installing a bot on your own server is easy to describe and hard to get right. You clone a repo, run a script, and a web app answers on your domain by lunchtime.

The question that decides whether the setup survives a second person is duller. What does the bot get when it starts work, and who else is holding the same thing at that moment? Three properties separate a demo from something a team can use. Each session needs a computer of its own, the sandbox needs a network path it can reach, and the rules need to live in files rather than in a settings screen.

The computer belongs to the session

Kortix gives every session a machine of its own. "One isolated sandbox per session. Each session has its own isolated machine and branch," the Kortix security page says.

Grok Bot takes the other route, and says so plainly. "Every Grok Bot shares one persistent cloud computer. Your Bots share that machine (files, browser, logins), so they can hand work off and keep context. Isolation is per user, not per Grok Bot," reads x.ai/bot. Two colleagues stay apart. Two bots belonging to one person do not, and neither do the browser profiles they left signed in.

The self-hosted bots land in between. OpenClaw runs one Gateway on your computer, offered as a personal assistant or a shared team deployment (openclaw/openclaw). Rakazo offers shared team computers or isolated private ones (elie222/rakazo). It runs on Docker, E2B, Daytona, CreateOS, Boat or a trusted local computer.

That last list is where a small studio gets caught. Two clients, two sets of logins, one browser profile. The second client's work starts from whatever the first left signed in. Afterwards, nobody can say which client sent the invoice.

A session with its own computer makes that collision impossible rather than unlikely. It is also why a per-account bot suits one operator, and turns into a liability in the first month a second client pays a bill.

Three ways to install it, and the one that starts nothing

The bootstrap runs on the server with a domain, an email address and a Platinum API key, installs Docker and the CLI, then starts the stack. kortix self-host configure asks for the admin email and the preview domain, and kortix self-host start applies the answers. Reachability is a flag on that first run, not a later setting. The three choices are documented at kortix.com/docs/host, and they differ in more than port numbers.

• Domain mode, --domain <domain>: the web app on the domain plus api.<domain>, with sessions running. The docs call this the production setup.
• Tunnel mode, --tunnel cloudflare: the web app on localhost:13737 and the API public through a trycloudflare URL, with sessions running. This is the evaluation path on your own machine.
• Local mode, neither flag: every port binds 127.0.0.1, and no session starts, because the sandbox cannot reach the API.

An install with no domain and no tunnel comes up and shows a login page, and it cannot run a single session. A stack answering on port 13737 looks finished, but every session it starts fails, because the sandbox has no route back to the API on loopback.

Five commands, and what each one leaves behind

The CLI is the whole setup. curl -fsSL https://kortix.com/install | bash puts it on the machine, kortix init my-agent creates the project, and kortix ship pushes it. kortix sessions new starts the first session, and kortix cr merge 1 lands what the session produced.

That shape differs from a hosted bot, where the account is the unit and the settings sit behind a login. Here the project comes from a command, and the session's work arrives as something you merge. The same commands run on a laptop and on a server. Moving between the two is a re-run, not a migration.

Where the rivals stop

Grok Bot reaches you through a desktop app on macOS or Windows and an iOS app, and the Bots it runs live on cloud computers that xAI hosts. The x.ai documentation covers network controls, audit logs, encryption in transit and at rest, and an organization-wide enable switch. It describes no deployment a customer installs. Nothing on those pages forbids running one elsewhere, and nothing there offers it either.

OpenClaw and Rakazo answer the same request with hardware you own. For a single operator that is the better trade: no subscription, the logins already in place, one machine to back up. Rakazo is still in beta, which is a fine place to be for a project under evaluation and a poor place to be for the machine your invoices run through.

The two cases split on whether more than one person, or more than one client, needs the same bot at the same time. Headcount rarely decides it. Where one operator is enough, a bot on a laptop will do. Where it is not, the computer has to belong to the session, and the network has to let that computer call home.

What the bill looks like when you own the box

Kortix runs on Kortix Cloud, in your VPC, or on your own on-prem network, with any model and your own keys. On your own network the software is open source. The rest of the bill is yours to read: the server, the model calls the sessions make, and the machine behind each session. None of those lines arrives with a price per person on it.

For a team weighing the two, the numbers sit on Grok Bot pricing and the head-to-head is at Grok Bot vs Kortix. The controls a security review will ask about are on Grok Bot security.