An open source Telegram agent on your server runs in three parts

Three questions behind one word

"Self-hosted" gets used as a single property. It is three. Which parts of the stack run on your hardware, which parts run somewhere else, and what you still own when the work is finished. A buyer who answers only the first question tends to assume the other two came with it.

Kortix is a fair place to test the distinction, because it answers each question differently. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free.

What a self-hosted instance puts on your machine

The platform goes on your server: the web app, the API and the database. A command-line tool installs, updates and checks it. The agent does not travel with it.

The Guide puts the platform on your server and states the limit in the same section. Sessions still run on cloud sandboxes from Platinum. They are not on your server. Those sandboxes call back, which is why your server has to be reachable from the internet.

The agent’s computer is rented by the session

The work happens on a machine that is not yours. One isolated sandbox per session. Each session has its own isolated machine and branch.

Files follow that machine’s clock. /workspace holds this session’s files, /drives holds shared folders that outlive it, and the home directory or /tmp can be empty when the session reopens. A long job that wrote its output to the wrong folder loses it overnight, which is a more common failure than any question about hosting.

Drive is the part that catches people. Every project has a Drive, and its folders are stored on Platinum, where sessions run. A contract filed in Drive is a file on Platinum, whatever name the web app is served under.

Where the company’s records actually live

Three different things get called company records, and they land in three places. The configuration is a git repo: the agents, their prompt files, the skills they load, the connector settings. Kortix can host that repo, or you connect your own on GitHub, so the files are yours even when the disk is not.

Memory can sit in the same repo, as a memory/ folder with MEMORY.md as its index. Agents edit it with their file tools, and each edit lands through a change request.

Session work reaches main through a change request. Merge is default-deny for agents. That gate is what makes the repo useful to a team: a diff, an author, and a second person who can refuse it. The open source page reads the file that defines one agent; the company tools page covers the logins behind it.

Connector credentials are brokered server-side and never enter the machine. The CRM login stays with the platform, so a command the agent runs in its sandbox cannot print it.

Connecting Telegram to an instance you run

The setup does not change with the host. Message @BotFather, send /newbot, and copy the token. In Kortix, open Project admin → Connectors, choose the Channels scope, select Connect on Telegram, and paste the bot token and the allowed Telegram user ids. Kortix keeps the token on the server.

Access is a list rather than an account link. Telegram has no account link, and the allowed-user list decides who may talk to the bot. A message from a listed person starts a session. Anyone else gets a reply showing their own user id. When the message comes in a private chat, that person also appears under Allowed users → Wants access, where a project manager allows them with one click. In a group the bot reads only commands, replies to it and mentions, so an ordinary message there never reaches it.

One chat is one session, and in a forum group each topic is a session of its own. The bot is the smallest piece of the arrangement and the easiest to mistake for the whole. It carries messages between a person on the list and a session running on Platinum, and moving the web app to your own hostname does not move that session.

The other route, and where review lands

OpenClaw takes the arrangement most people picture when they hear self-hosted. It is open source and runs on your machine, with no subscription and no hosted tier, and it is stewarded by an independent 501(c)(3). Its Telegram integration is production-ready for bot DMs and groups via grammY, with a default DM policy of pairing, group allowlists and exec approvals.

The default setup puts one person on a machine they already use, and that is not the only shape. Multi-user mode lets several trusted people operate the same agent, with session ownership, participant history, live presence and owner filtering. On a shared server, each person's model sign-in stays their own instead of becoming a shared credential. OpenClaw's docs say what the mode is for: ownership and presence are usability features, not security boundaries, and people who must not reach each other's sessions need separate agents or separate gateways.

Where the routes part is review. The agent works on the machine and its state sits with that installation, so a change is not a change request with a diff, an author and a merge a named person can refuse. A team that wants a diff read before it lands keeps that habit around the machine.

Which one fits

If one person owns the work and the machine is theirs, the all-local route keeps everything in one place. A small team can share a server there and let multi-user mode track who owns what, with the review gate still a habit rather than a rule. If the work needs a repo, a change request and a second reader built in, the split gives you those and rents the computer by the session.

The word invites one assumption worth correcting. If the rule is that no company data leaves the network, the split does not satisfy it: the session’s computer and Drive sit on Platinum, and the project repo lives wherever you host it. What your server holds is the platform. A company with a stricter rule needs a different arrangement, and should know that before the install.