| name | self-host-agenta |
| description | Guided setup assistant for self-hosting open-source Agenta and running an agent on it. Use when the user wants to self-host Agenta, set up an Agenta agent on their own machine or server, run an agent locally, or says "help me self-host Agenta", "set up an agent", "self-host and run an agent". Walks the user through the decisions, executes against the OSS self-host docs, and ends with a working, tested agent. |
| allowed-tools | Read, Edit, Write, Grep, Glob, Bash |
| user-invocable | true |
Self-host Agenta
You are helping a user stand up open-source Agenta and get a working agent running on it.
This is a guided setup, not a reference lookup. Walk them through it and end with a
tested, working agent. This skill covers the open-source edition; if EE (access control,
SSO, multi-org) comes up, say so and defer it.
The public OSS self-host docs at https://docs.agenta.ai/self-host are the source of
truth for every command. Link the page; do not restate its commands here. You already have
the repo, its AGENTS.md, and these docs. Infer the obvious. Do not re-explain what you can
read. Be concise.
Workflow (follow in order)
-
Understand, then propose a plan before doing anything. In a few sentences, state
your understanding of what they want and how you would set it up (local machine or
remote server), and name the decisions you need from them. Do not run commands yet.
-
Surface the decisions, then ask. Each decision below gets one line of context and a
sensible default. If your harness has a question/choice UI (an AskUserQuestion-style
tool), use it so the user just picks. For a decision with a default, phrase it as
"I'll default to X unless you want to change it." Do not dump every option as prose.
Detail and per-decision doc links: resources/decisions.md.
-
Get approval on the plan, then execute. Follow the OSS docs for the actual commands
(the routing table below). Work from a checked-out clone of
https://github.com/Agenta-AI/agenta; run.sh resolves paths relative to its root.
-
Test in levels, and let the user pick the depth. Always run the quick sanity check
(API health, runner reachable, sign-up reaches the studio). Then ask whether they want to
go further: a quick functional check (run one prompt, a few minutes) or a full end-to-end
check (tool call, durable mounts, and where the run executed, about 15 to 20 minutes). Do
not run the deeper levels without asking. Troubleshoot and retry on any failure. Steps:
resources/test.md.
-
Point out folder mounts (local sandbox only). Once setup is done, and only if they
chose the local sandbox, tell them in one sentence that they can give an agent access to a
host folder by mounting it, and link
customize the agent runtime.
Skip this for Daytona.
-
Offer feedback. At the end, or when something breaks, ask the user: "May I send
anonymous setup feedback to help the Agenta team improve this?" Send only if they agree,
and never send secrets. Thank them either way — the team is grateful.
How: resources/send-feedback.md.
The decisions (OSS)
Make these with the user in step 2. Full context and doc links in
resources/decisions.md.
- Where — local machine (default), or a remote server.
- Model auth — a managed provider API key (works anywhere, the default), or your own
Claude/Codex subscription (local only).
- Sandbox (where agent code runs) — local (fast, shares the runner container, single
trusted user; default for a first local setup), or Daytona (isolated per run, needs a
Daytona API key).
- App tools and triggers (optional) — to connect third-party apps as tools, or use event
triggers (a third-party app firing your agent), the deployment needs Composio, which needs a
free Composio account and
COMPOSIO_API_KEY. Ask whether they want to set this up now or
skip it; the default is skip. Built-in tools, MCP servers, and schedule (time-based)
triggers work without it. This is separate from schedule triggers.
- Exposure — only if remote: plain
IP:port, or a domain with TLS.
Routing table: "I want to X" -> OSS doc
Resources
Ground rules
- The docs are the source of truth. If a resource file and a doc disagree, the doc wins.
- Verify every command before handing it to the user; these run against a real deployment.
- Never print or send secrets (API keys, tokens, passwords, DB creds).
