Capka
Give Capka the work.
Get the finished files.
Give Capka a task and the files it needs. It works through them in its own Linux sandbox and gives you back the finished report, spreadsheet, document or code.
Open source · Self-hosted · Your models
One messy ZIP in → PDF report + Excel out
This is what people write to it
On the left, what was attached. On the right, what came back.
“Pull this into one table. Show me the deals where the margin is way below normal, and the clients who stopped buying in May. At the end, briefly: what should I check.”
“Work out what we agreed with the contractor and how it kept changing. Deadlines, cost, what they were supposed to deliver. Show me where the documents and the emails don’t line up.”
“Have a look at what changed for them over the week. New features, prices, plans, anything they announced. If nothing much happened, just say so.”
One server. Everyone gets their own desk.
Start on your own, and invite the team to the same server later. One Capka instance serves everyone: models, keys and tools are configured once, while each person keeps private chats, separate files and isolated running tasks.
- Personal space. Files, chats and running tasks are strictly separated between users
- Shared setup. Model API keys and connectors to your services are configured once for the whole instance
- Admin privacy. Admins see token spend and manage access — other people's chats and files never appear in the admin panel
- Guardrails. Allow, ask or deny rules for what agents may do, an audit log of what happened, control over the sandbox reaching the internet, and registration closed by default
And every task gets its own computer
That is why it can run code, install what it needs and work with your files — and why one task never sees another’s data, touches another’s files or holds anything up.
A separate Linux sandbox for every chat
files · tools · code
Python · Node · LibreOffice
FFmpeg · Playwright · OCR
- A real machine. It installs packages, runs scripts, opens a browser, converts documents
- Files stay put. Each chat keeps its own directory between sessions
- Close the tab. The task keeps running on your server, files waiting when it is done
Containers run unprivileged and cannot touch the host filesystem. For public instances or untrusted users, isolation can be hardened further with gVisor or rootless Docker.
Set it once. Capka takes it from there.
Describe the task once and pick a time. Capka starts a fresh task at the right moment and leaves the finished files waiting — daily, weekly, monthly or on a single chosen day.
- Every run starts clean. Capka executes the saved instruction from scratch, so an old conversation never leaks into a new report
- Pause it, or run it now. Any automation can be put on hold or triggered by hand without touching the schedule
- The result is an ordinary chat. Open the run, read what it did, ask it to redo a part — nothing is hidden in a log
Monday can start with the report already written, not with writing it.
Teach it how your company works
Your procedures, templates and recurring workflows become skills Capka reuses. Your databases, APIs and internal services become tools it may reach — and you decide which ones.
Ready-made bundles come from the marketplace, and before one installs you see what it will reach: which hosts, which commands, which secrets. Agent Skills · MCP · OAuth
The whole platform, right in Telegram
Not a notifications bot or a quick-question toy. The full platform lives in the messenger: sandboxes, file work and full context.
- Send files, get files back. Documents, spreadsheets and archives go through the same sandbox as on the web.
- One chat, one project. Start a fresh Telegram chat per project; they never bleed into each other
- Move to the web when you need it. Review Telegram chats in the web app and continue there in a copy of the chat
Why Capka
- Finished files, not a chat reply
- Runs on your own Linux server
- Your models, your keys, no per-seat fee
- A separate sandbox for every task
- The whole team on one instance, each with private files
- Recurring work runs on a schedule
Compare with Claude Cowork, OpenClaw, Suna, Open WebUI and Onyx
This corner is no longer empty, so here is an honest map. Hosted agents like Claude Cowork return finished files, but keep them in their cloud. Self-hosted ones exist too: OpenClaw is an excellent personal assistant, Suna runs real Linux sandboxes — yet one is built around a single trusted operator, and the other leans on hosted Supabase and Daytona. Capka is the self-hosted, open-source alternative for a team sharing one small server: finished files, a separate sandbox per chat, roles and spend you can see.
| What you get back | Where it runs | Tradeoff | |
|---|---|---|---|
| Claude Cowork | Finished files | Their cloud | Per-seat cloud service; files leave your infrastructure |
| OpenClaw | Files and actions | Your server | A personal assistant by design; shared access is a convenience, not isolation |
| Suna | Finished files | Your server, plus hosted services | Real sandboxes, but needs hosted Supabase, Daytona and Composio alongside |
| Open WebUI | Chat replies | Your server | A strong chat UI; not centered on per-task file sandboxes |
| Onyx | Knowledge-base answers | Your server | Enterprise knowledge and search stack with a larger footprint |
| Capka | Finished files, on your server | Your Linux server | You operate the server and pay for compute and model usage |
Use Capka if
- you need a finished file back: a report, a patch, a clean dataset, not a chat reply
- your files can't leave your infrastructure
- you want to choose models yourself and pay for tokens, not per-seat subscriptions
- you have a small Linux server, or don't mind renting one
Skip it if
- you just want to talk to a bot without files: a plain chat app is simpler
- nobody wants to run a server: hosted products exist for a reason
- you need vendor support and an SLA: Capka is open source, support lives in GitHub issues
Your server. Your models. Your rules.
Capka deploys on a Linux server with Docker. Plug in your own API keys, pick model providers, or run local models through Ollama.
curl -fsSL https://raw.githubusercontent.com/LyoSU/capka/master/install.sh | bash
Prefer to inspect scripts first? Read the installer on GitHub.
You are installing v0.25.0, released
The installer will
- install Docker if it is missing
- pull the prebuilt stack
- create the secrets
- start Capka
You will need
Linux, x86_64 or arm64 · Docker · from 2 GB RAM and 20 GB disk, 4 GB recommended
On first open: create an admin, connect a model, start working.
Common questions
How isolated is each chat, really?
Every chat runs in its own Linux sandbox with separate file storage. Containers are unprivileged and can't touch the host filesystem, and contexts never mix between chats or users. For public instances or untrusted users you can harden it further with gVisor or rootless Docker — see the security guide.
How is this different from OpenClaw or Suna?
Both are good at what they were built for. OpenClaw is a personal assistant: its own documentation calls shared access a usability feature rather than a security boundary, and suggests separate gateways when people must not reach each other's files and credentials. Suna runs real Linux sandboxes, but expects hosted Supabase, Daytona and Composio next to it. Capka is built for a team on one small server: every chat gets its own sandbox, files and chats stay private per person, and the admin panel shows roles and spending rather than conversations.
What stops a malicious plugin?
Two different things, and they are worth separating. Before a marketplace bundle installs, Capka shows what it will reach — which hosts its connectors talk to, which commands run in the sandbox, which secrets it asks for — and an update that widens that access stays blocked until you accept it. That is informed consent, not a restriction: the real boundary is the sandbox itself, where anything installed runs unprivileged and without access to the host filesystem. Admin policies — allow, ask, deny — and the audit log cover what happens afterwards.
What server does it need?
A basic Linux VPS with Docker: 1–2 vCPU, 2 GB RAM and 20 GB of disk are enough to start. No Kubernetes and no zoo of microservices — unlike most self-hosted AI platforms.
Whose API keys and models does it use?
Yours. Plug in providers you already pay for — Anthropic, OpenRouter, any OpenAI-compatible API — or run local models through Ollama. Use one shared key per instance, or separate keys per user.
Do my files leave the server?
Uploads, working folders and results stay stored on your Capka instance. Content needed for a task may be sent to the model provider you configure; with a local model, it can remain entirely inside your infrastructure.
Is it really free?
The software is free under AGPL-3.0 — run it, inspect it and adapt it. You cover your server, storage and model usage; Capka adds no per-seat subscription.
What does running it actually cost?
Two bills, both paid by you directly: the server, and the model provider whose keys you plug in. Capka takes no cut and adds no per-seat fee, so a quiet month costs close to nothing beyond the VPS. Heavy file work costs more because it burns more tokens — the admin panel shows spend per person, so you see it before it surprises you.