Self-hosted Gumloop: run the open-source alternative yourself

What self-hosting actually changes

When a team leaves a hosted, build-it-in-the-browser tool, the real question is where the system lives. With Kortix, the whole thing is a git repo you own. Agents, skills, memory, connector config and triggers are text in that repo, and kortix.yaml at its root declares the machine image, the connectors and the triggers. You can grep the whole company, diff any change, and roll any part of it back.

Sessions do not run inside a shared vendor account. Each session gets its own isolated machine and branch, so one agent's work cannot reach into another's. Connections are the part teams ask about first: connector credentials are brokered server-side and never enter the machine, and secrets are encrypted at rest with a key per project. Nothing merges itself either. Session work reaches main through a change request, and merge is default-deny for agents, so a person reads the diff before it lands.

The model layer stays yours. Any model provider with your own keys, or the ChatGPT plan you already pay for, and the repo records which agent uses which model. Run it on Kortix Cloud, in your VPC, or on your own on-prem network.

Can you self-host Gumloop?

Gumloop is a hosted product. You build agents in their web app and they run in Gumloop's cloud, and its plans are Pro and Enterprise only. There is no Gumloop image or on-prem install to deploy, so a "self-hosted Gumloop" really means a different system that you run yourself.

Kortix is that different system, and it is open source. Self-host is free, and the agents, skills, memory and connectors stay in a repo you own rather than in someone else's database. The difference is architectural: one is a hosted builder you rent, the other is a system you operate.

If cost is the deciding factor, the Gumloop pricing breakdown puts the two billing shapes side by side, and the Gumloop alternatives page covers the wider field of hosted and self-hosted options.

What it takes to run it

One command, kortix self-host start, brings the stack up as a Docker Compose stack. The first interactive setup asks only for the integration credentials that unlock managed git, GitHub access and connectors; ports, local URLs and keys are generated for you. GitHub connects later in the dashboard under Settings, and models are bring-your-own-key in the app. The stack has no Redis and no separate worker process, so there is less to keep alive.

A note worth stating plainly: self-host start pulls its images from Docker Hub, so this is a self-hosted install rather than a disconnected one. The instance still needs to be reachable so a sandbox can call back to it.