Skip to content
OpenManus Alternative
OpenManus Alternative

Self-host an open-source OpenManus alternative

If you run OpenManus and want a self-hosted alternative your team can govern, Kortix is the open-source AI Operating System that runs as one stack on your own server. OpenManus leaves a box, a key and a loop to you; Kortix puts the system around them.

The setup you keep, in two shapes

The framework you assemble, and the platform you self-host.

OpenManus
$ conda create -n open_manus python=3.12$ conda activate open_manus$ git clone https://github.com/FoundationAgents/OpenManus.git$ pip install -r requirements.txt$ cp config/config.example.toml config/config.toml$ python main.py
Source: https://github.com/FoundationAgents/OpenManus
terminal
$ curl -fsSL https://kortix.com/install | bash$ kortix self-host init --domain kortix.example.com --admin-email you@example.com$ kortix self-host start
Source: https://kortix.com/docs/host

What self-hosting OpenManus asks of you

OpenManus is an open-source framework for building general AI agents, in its own words, and it runs on a Python environment you set up yourself. Its repository documents the shape: create a Python environment, clone the repo, install the dependencies, copy config/config.example.toml to config/config.toml, add a model API key, then run python main.py. The agent then lives on one box, under one key, in one terminal loop (OpenManus repository).

That is real freedom and very little system. The framework ships no team governance, no shared memory, no review gate, and no hosted path. Whoever runs it holds the box and the key, nothing records what the agent did, and nothing holds it back before it acts.

What self-hosting a platform gives back

Kortix is the open-source AI Operating System, and self-hosting it runs the whole platform rather than a trimmed build. One Docker Compose stack, installed, configured and updated by the kortix self-host CLI, runs the whole platform on a server you control. The control plane stays inside your network: accounts, projects, repos, secrets, connectors, policies and the audit log sit on storage you back up yourself (Read the docs).

What the platform adds is the part the framework leaves to you:

  • Agents, skills, company memory and connector rules are files in one git repo you own, versioned and reviewed like code.
  • Per-resource permissions for people and agents, roles, groups, and an audit trail.
  • Approval gates you set, off until you set them, with merge default-deny for agents.
  • Secrets encrypted at rest with a key per project, and connector credentials are brokered server-side and never enter the machine.

Sessions add isolation without adding servers to your rack. Every session runs on a sandbox provider, Daytona by default, or Platinum or E2B, on its own isolated Linux sandbox and branch, and the sandbox calls back to your instance's public API. Session work reaches main through a change request a person approves.

The self-hosting decision

The two paths answer different questions. OpenManus answers whether you can run an agent today. Self-hosting Kortix answers whether a team can own and govern the system that runs its work.

Pick the framework while one person is prototyping and the box and the key can live on one desk. Pick the platform when several people share the agents, the review has to leave a trail, and the configuration has to outlast the person who set it up.

You can run both. Point Kortix at the model providers you already pay for, and keep the framework for the experiments. The alternatives page and the head-to-head with OpenManus take the decision further.

What stays on your side

Self-hosting keeps the data and the decisions close. The Postgres data directory, the storage directory and the .env that holds every key are the instance, so backing up those three backs up the whole thing. Model calls route through the gateway running on your own box, over your own domain or tunnel, and Kortix holds no credential in that path.

You can run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free.

The parts of a self-hosted Kortix

Four layers, each one a file or a service you can point at.

  1. The repo

    Agents, skills, memory and connectors are files

    One git repo is the system, versioned and reviewed like code.

    kortix.yaml
    # kortix.yamlagents:  support-triage:    file: agents/support-triage.md    connectors: all
    Source: https://github.com/kortix-ai/suna
  2. The stack

    One Docker Compose stack runs the platform

    The CLI installs, configures and updates every service on your server.

    stack services
    frontend        The web app.kortix-api      The REST API at /v1.llm-gateway     The standalone LLM gateway.kortix-migrate  It migrates the database before kortix-api starts.
    Source: https://kortix.com/docs/host
  3. The control plane

    Your models, your gateway, your keys

    Model calls route through the gateway inside your own stack.

    terminal
    # stored as an encrypted project secret, injected at session boot$ kortix providers set anthropic sk-ant-...$ kortix providers login chatgpt$ kortix providers ls→ anthropic · openai · openrouter
    Source: https://kortix.com/self-hosted
  4. The sessions

    Sandboxes run off the box, on your provider key

    Each session is its own isolated Linux sandbox on its own branch.

    sandboxes
    Sandboxes. Every session runs on Daytona (the default), Platinum or E2B.kortix-api creates them with your provider key.The sandbox calls back to the instance's public API URL, KORTIX_URL.
    Source: https://kortix.com/docs/host

Self-hosting questions

Yes. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free. Sessions then run on your own sandbox provider account and your own model keys, so those costs sit with those providers.

No. Sessions run on a cloud sandbox provider off the box, Daytona by default, or Platinum or E2B. Because those sandboxes call back to the API, the instance has to be reachable from the internet.

Secrets are encrypted at rest with a key per project, and connector credentials are brokered server-side and never enter the machine. Model calls route through the gateway inside your own stack, over your own domain or tunnel.

Yes. A host is one Kortix API endpoint with its own token, and kortix hosts use selfhost or kortix hosts use cloud switches the CLI between your own instance and the managed cloud.

Run the whole system on your own server.

Self-host Kortix for free, or start on the managed cloud and move when you are ready.

Open source · Any model, your keys · Self-host, VPC, or on-prem