Self-host an open source Discord agent, knowing which half you run

The two halves of a self-hosted Discord agent

Self-hosting a Discord agent splits the stack in two. One half holds what makes the agent yours: the project, the grants, the channel connection, the record of what ran. The other half runs the work. It can sit somewhere else entirely.

Kortix names the split on its self-hosted page. The naming is the useful part. kortix self-host init writes one Docker Compose project, and every service in that project runs on your server. Sessions and Drive do not. They run on Platinum sandboxes, and each sandbox calls back to the instance you just installed.

That one sentence settles most of what a security review asks. Where the database sits. Where file storage sits. What a server backup contains. Which host has to be reachable from the internet. Which credential a running agent can see.

What stays on your server

The install is one stack. The page describes it this way: "The kortix CLI installs the web app, the API, the LLM gateway and the database on your server as one Docker Compose stack. Then it keeps the stack up to date."

The services, in the page's own list:

• frontend, the web app, which is where you add the Discord app and set the rules
• kortix-api, the REST API, which brokers connector calls
• llm-gateway, which carries model requests to the provider a project connects
• supabase-*, Postgres, auth and file storage
• kortix-updater, which pulls images, migrates and rolls the stack once a day
• caddy, which terminates TLS on ports 80 and 443 in domain mode

The image you run on that server is the same code anyone can read. That is why the service list is checkable rather than a claim on a slide.

Two consequences follow. The audit record is written by the API on your machine: "Every action is recorded. Reading, exporting and streaming the audit log depend on the plan." And the Discord connection is configured from your own Project admin. The thing that holds the channel is an instance you can open a shell on.

What does not, and the reachability that follows

"Sessions and Drive run on Platinum sandboxes. They call back to your instance."

One isolated sandbox per session. Each session has its own isolated machine and branch. The work happens on a cloud computer that is not the server in your rack. Drive folders and App volumes are Platinum volumes too. The docs state the backup rule plainly: Drive folders and session workspaces live at Platinum, so a server backup does not hold them. If your retention policy covers the company's files, it has to cover both places.

The callback decides your network. The docs say the instance must be reachable from the internet so those sandboxes can call back. The stack also pulls its images from Docker Hub. Your server needs an inbound path and outbound access. Point DNS at it and Caddy gets a certificate on 80 and 443, or run a Cloudflare tunnel while you evaluate. A host with no route in and no route out starts its containers and fails at the first session.

If the review calls for an isolated topology, that is scoped with the Kortix team over the install. The page is direct that the standard stack is not that topology. A page that says so is worth more than one that lets you find out on day two.

The install path

Four commands on a Linux server with Docker, then you sign in at your own domain. The CLI runs on Linux and macOS, on x86_64 and arm64. The bootstrap script is Linux only.

kortix self-host init asks the setup questions once. It writes docker-compose.yml, .env, a Caddyfile and updater.sh into ~/.config/kortix/self-host/<instance>/. --yes keeps the defaults when you script it. kortix self-host start runs docker compose up. kortix self-host configure asks the questions again when something changes, and writes the files without applying them until you start. kortix self-host doctor checks the result and exits non-zero on a failing check. Put it in the runbook.

There is a laptop path too. kortix self-host init --tunnel cloudflare then kortix self-host start opens the web app at http://localhost:13737 and publishes the API on a trycloudflare.com URL. That URL changes each time the tunnel restarts. Fine for an evaluation, wrong for a team.

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

Updates, pinning and rollback

The stack updates itself. The page lists daily updates, a choice between stable and latest, a database migration that runs first, and a rollback in one command. All of it runs from the same CLI. The updater service pulls new images once a day, migrates, then rolls the application services.

The failure behaviour is the part to know before you enable it on a Friday. A failed migration swaps nothing, and the previous version keeps serving; a failed swap keeps the previous version too. kortix self-host status reports the outcome of the last run, and kortix self-host doctor covers the wider set of checks. Pin one exact version when a change window is closed. The instance directory and its Docker volumes are the backup unit. Stop the stack before you copy them.

Where the Discord app token and connector credentials sit

The Discord side starts with an application you create, and a bot token that belongs to it. You add the app to the server from Project admin, on the Connectors page under the Channels scope. You need the Manage Server permission there. On a self-hosted instance that flow runs against your own API, so the service making Discord calls is kortix-api, on the machine you installed.

Every other connector follows the same route: "Connector credentials are brokered server-side and never enter the machine." A session that reads a ticket or posts a reply asks your instance to make the call. The sandbox never holds the Discord token, the CRM login or the mail password, and the credential stays on the server side of the request.

One setting is worth checking at install time. Without the Message Content intent the agent reads mentions, direct messages and its own messages. A self-hosted instance that enables the intent can pass every message in a Kortix thread to the agent. The switch is DISCORD_MESSAGE_CONTENT. That is a decision about your server, which is the point of running one.

The word without the split

OoriData's Discord-AI-Agent is the other open source option a searcher meets. It is a Python bot you run yourself. Install with uv pip install -U ., copy config/example.main.toml to config/main.toml, then pick a provider and put its key in the environment. You run all of it, including the process that holds the key. AgentX, Beam.ai and Mava are hosted and closed, and none of them lists a self-host option.

So the word fits a bot process and strains on a product. Put four questions to any vendor: which services run on my server, where the sessions run, what a backup contains, which host has to be reachable. A page that names those four things is a deployment. A page that says self-hosted and stops is a word.