AgentSwarms Is Now Source-Available: Self-Host the Full Agentic AI & BI Platform

For the last year, agentswarms.fyi has been a classroom: guided curriculum, build-along labs, runnable notebooks, patterns and certification for people learning agentic AI. The question we got most often was not about a lesson. It was: “this is great, but can I run the platform itself — on my own infra, against my own data?” As of today, yes. AgentSwarms is source-available on GitHub, and it ships the whole thing: agent chat, a visual multi-agent swarm canvas, knowledge bases with RAG, MCP, connected warehouses, dashboards, budgets and full execution traces.

The repo lives at [github.com/AgentSwarms-fyi/agentswarms](https://github.com/AgentSwarms-fyi/agentswarms). It is licensed under the Elastic License 2.0 — you may freely use, self-host, modify and redistribute it; you may not resell it to third parties as a managed service. Everything else is yours: your Supabase project, your provider keys, your Docker host, your data.

Two products, one UI, two missions

It helps to be blunt about the split, because they are genuinely different things wearing the same interface.

• agentswarms.fyi (hosted) is a learning-first environment. Curriculum, build-along labs, interactive notebooks, presentations, community galleries, certification, free tools — all managed, with a free-tier AI gateway so you configure nothing. You come here to study and practise.
• The repository (self-hosted) is a deployment-first platform. The same agents, swarms, RAG, connected data, dashboards, traces and budgets — but running on your infrastructure, with your provider keys, no usage caps beyond the budgets you set yourself. You go there to run something real.

What actually ships in the repo

Agent Chat, with Visual BI and document generation

Build an agent, wire up tools, chat with it in-browser, and read the full request/response trace afterwards. Turn on Visual BI and the answer arrives with a chart computed from your connected tables — and the SQL that produced it listed as the source, so the number is checkable rather than asserted. From the same conversation you can generate a real, editable PowerPoint, Word document or Excel workbook; the Excel can pull every row with live formulas rather than a pasted snapshot.

The swarm canvas

Design a multi-agent workflow as a graph. Each node is a step — agent, router, condition, loop, human approval, tool call — and the inspector sets its provider, model, prompt, tools and knowledge. The important detail is that the same graph runs from the canvas, from the API, and on a schedule. What you draw while prototyping is what runs in production; there is no second implementation to keep in sync.

A real BI workspace

This is the half that surprises people. Multi-page drag-and-drop dashboards over local datasets or connected warehouses, with cross-filtering and drill-down on every chart type, drill-through to underlying rows, pivot matrices with subtotals, dashboard filters with date presets, version history, scheduled refresh with email reports, incremental refresh, SQL aggregation pushdown, data alerts, and row-level security plus column-level masking enforced server-side on shared dashboards. Organise them into workspaces and folders, promote a personal draft into a shared workspace, and export model and dashboard definitions to a Git repo.

Knowledge, tools, MCP — and an MCP builder

Knowledge bases with RAG, web_search and web_browse tools (working out of the box with a free fallback, or Firecrawl/Brave/SerpAPI/Tavily for real workspace-wide search), encrypted per-user provider keys, MCP client connections, swarm export to LangGraph / CrewAI / OpenAI Agents SDK / Strands, and an A2A endpoint. Newer than the client half: an MCP Builder that lets you author a FastMCP server in Python, deploy it to a sandboxed kernel, and get a real Streamable-HTTP endpoint — with hashed API keys, per-tool and per-IP limits, and a redeploy that changes any tool name or schema blocking calls until you re-approve it. That last control is the anti-“rug pull” guard MCP's own security guidance asks for.

A developer workspace with real kernels

Python notebooks on sandboxed server kernels — actual CPython with a working pip install and genuine langchain, langgraph and llama_index imports, not a browser emulation. The built-in agentswarms helper calls your connected models, searches your knowledge bases, and runs your saved agents and swarms, all governed by IAM rules and logged in Traces. No provider key ever exists inside the sandbox. A notebook can be published as a callable API and versioned to Git as plain Python.

Observability, IAM, guardrails

Every tool call, token and dollar shows up in an execution trace, alongside an audit trail of who did what — model calls, dataset and warehouse queries, dashboard views — with a configurable retention window and admin-only spend analytics by user and group. IAM covers superadmins, groups, invite or manual provisioning, per-user and per-group model allow-lists, and invite-only mode. Guardrails and evals ship too: prompt-injection tests, PII redaction, and LLM-as-judge scoring you can run against your own agents.

Getting it running

There is no separate backend to install: Supabase _is_ the backend (Postgres + Auth + Storage), run as a free-tier hosted project. Create one, drop its keys into .env, and the setup script handles secrets, dependencies, migrations and bringing the stack up.

git clone https://github.com/AgentSwarms-fyi/agentswarms.git
cd agentswarms

cp .env.example .env      # fill in your Supabase keys, then:
bash scripts/setup.sh     # Docker stack  ->  http://localhost:8080

# bash scripts/setup.sh --dev      # local dev server instead
# bash scripts/setup.sh --docgen   # + server-side PPTX / DOCX / XLSX renderer
# Windows: powershell -ExecutionPolicy Bypass -File scripts\setup.ps1

Prefer doing it by hand, or deploying to a VPS / Fly / Railway / Render / Kubernetes? The manual path is equally short.

npm install
cp .env.example .env
npx supabase login && npx supabase link && npx supabase db push   # schema, once
npm run dev            # -> http://localhost:8080

# or, containerised:
docker compose up --build

From lesson to production: a suggested path

The fastest way to a self-hosted system you trust is not to start with the self-hosted system. Learn the shape of each piece here first, where a broken run costs nothing, then port it.

1. 1Start in the curriculum. Work the foundations, tool-use and RAG tracks on /curriculum until an agent loop stops looking like magic — prompt, tools, observation, next step.
2. 2Run the notebooks. The /notebooks tracks cover LangChain, LlamaIndex, Google ADK, OpenAI Agents SDK, Strands, Mastra and Vercel AI SDK with pre-baked outputs, so you can read them before you run them. This is where the self-hosted developer workspace will feel familiar.
3. 3Prototype in the playground. Build the actual agent you have in mind on /playground with the free hosted gateway. Get the prompt and tool set right before any infrastructure exists.
4. 4Draw the workflow on the swarm canvas. If one agent is not enough, model the routing, loops and approvals on /swarms. Export it — the canvas emits LangGraph, CrewAI, OpenAI SDK and Strands.
5. 5Prove the failure modes. Run guardrail and eval labs against your prototype. A use case that survives prompt-injection tests and an LLM-as-judge pass is one worth deploying.
6. 6Then self-host. Clone the repo, point it at your Supabase project and your provider keys, and rebuild the same agent — but now over your real knowledge bases and warehouses, with IAM, budgets, traces and dashboards around it.

Use cases worth building first

Self-hosting only pays for itself when the data is data you could not have uploaded anywhere else. A few that fit the platform's shape well:

• A BI analyst over your warehouse. Connect the warehouse, define a semantic layer, and let people ask questions in plain language with the generated SQL shown as the source. Row-level security and column masking are enforced server-side, so finance and support can share one dashboard safely.
• A grounded internal assistant. Point knowledge bases at your policies, runbooks and contracts. Because the corpus never leaves your Supabase project, this is the use case teams usually cannot do on a hosted product at all.
• A scheduled research or monitoring swarm. A graph that fetches, summarises, checks against your data and mails a digest — the same graph on the canvas, the API and the schedule.
• Board and QBR document generation. Query the warehouse, then have the agent emit a real PowerPoint or an Excel with live formulas, rather than a screenshot of a chart.
• An internal MCP layer. Wrap your internal APIs as FastMCP servers with the MCP Builder, expose them with hashed keys and per-tool limits, and let every agent on the instance use them.

Contributing

Issues, PRs and hard questions are all welcome — CONTRIBUTING.md has the workflow, and SECURITY.md covers responsible disclosure if you find something sharp. If you deploy it and build something interesting, we would genuinely like to hear about it; that feedback is what shapes both the platform and the lessons here. And a star on the repo helps other people find it.