Self-host an open‑source Tasklet alternative that starts sessions

What self-hosting has to mean when agents do the work

For a chat product, self-hosting is a deployment question. The app goes on a server, DNS points at it, and the feature set arrives unchanged. An agent product behaves differently, because a session needs a computer to work on, and that computer is not the one you installed the app on.

A Kortix install puts the control plane on your server: the web app, the API, the database, the LLM gateway, the object store. Each session is then created on its own cloud computer through Platinum, the compute provider the install defaults to. That machine does not live inside your server. It is created with your Platinum key and it calls back to your instance’s public URL to pick up a prompt, report progress and open a change request.

That loop explains the rest of the setup. The install does not need a large server. It needs a server the sandbox can reach, and it needs one before the first session starts. The self-hosting section of the developer docs states the same requirement in its table of reachability modes.

The three modes, and the one that fails without saying so

kortix self-host init asks a question most install guides skip: where will your instance answer from? There are three answers, and only two of them produce a working install.

The third row is the trap, and it is quiet. The install finishes. The web app loads on port 13737, you sign in, you create a project, you start a session. Then the session sits there and nothing in the terminal says why. The cloud computer was asked to call an API at a loopback address, and to a machine in another network, 127.0.0.1 is itself.

Domain mode is the production setup, and it needs three DNS records pointed at the server before the first start: the domain, api.<domain>, and the wildcard *.p.<domain> that sandbox previews use. The docs ask for that wildcard on every public instance, because without it browser previews fall back to a path proxy that breaks root-absolute links and the doctor check fails. With the records in place, open ports 80 and 443 and let Caddy fetch the certificate on the first start.

Tunnel mode is for evaluation on your own machine. The web app stays on localhost, cloudflared publishes the API at a trycloudflare.com address, and that address changes each time the tunnel restarts unless you create a named tunnel in Cloudflare.

Both of those modes need the same thing underneath, which is a key that has nothing to do with the server you just configured.

What the month actually costs

Self-host is free. That is a statement about the platform, not about the month. Four lines appear on the bill a self-hosted install creates.

The server is the first. A Linux host with a public IP, Docker installed by the bootstrap, the three DNS records domain mode asks for, and inbound ports 80 and 443. A modest machine carries the control plane, because the work does not run there.

The Platinum key is the second, and it is the one people miss. Sessions are created on your Platinum account, so that compute is a separate line from the server, and without the key sessions do not start at all. The model key is the third, added in the web app after the first sign-in rather than during the install.

The fourth line is a person. The installer writes an updater that pulls new images once a day, migrates the database and restarts the services, and it holds the Docker socket to do that. Upgrades arrive on their own until one fails at an inconvenient hour, and then somebody has to read the output of kortix self-host doctor and decide what to do. Count that time before you count the savings.

None of these lines is large on its own. Together they are why a $25 a month managed plan can still be the cheaper answer for a small team. A team that already runs servers finds the arithmetic easy in the other direction.

What stays yours on your own server

The repo is the first thing. Agents, skills and company memory are files in a git repository you own. A change to an agent arrives as a diff, not a settings screen somebody edited in June. Approval gates you set. Off until you set them.

The credentials are the second. Connector credentials are brokered server-side and never enter the machine. On a self-hosted install the credential store sits on your server, not in a working directory a session can read.

The record is the third. Sessions, accounts and change requests live in a Postgres database in the same install, on your disk. The history of the configuration is the git log beside it. When a contract ends or an auditor asks, nothing needs exporting, because none of it ever left.

You take on a server, a key and an upgrade path. In return the definitions, the credentials and the record arrive in a form you can open without asking anyone.

Where a managed product is still the right answer

Tasklet is a managed cloud product: agents run in Tasklet’s isolated cloud environments and keep working after you close the app. There is a free tier with trial credits and no card, then plans from $25 a month for casual use and $100 for power use, with a $250 tier and custom amounts up to $10,000. Starter at $25 carries 10,000 credits, Pro at $100 carries 40,000, and the $250 tier carries 100,000. The company states it is SOC 2 Type II compliant, all of it on its pricing page. Tasklet does not publish an open-source version, and its site offers no self-hosted install.

For a team of three with nobody on call, that is a fair buy. The first agent works before lunch, the patching is somebody else’s job, and the bill is a number you can predict. Self-hosting earns its keep when the question changes. It is the answer when somebody needs to read the code before it gets a key to the invoicing system, or when the agents do enough work that a server and a Platinum key cost less than the subscription.

Dify is the other open-source name that comes up for this question, and it belongs in the answer. Dify is an open-source platform for building LLM apps and agents, self-hosted with Docker Compose or bought as a cloud workspace, and its install guide starts with a Compose file. If that is the shape of your project, start there. If the shape is an agent that owns a job and needs a computer of its own, the reachability question decides whether your install works at all.