Integrations
It works with what you already have
Capybari does not want to own your git host, your servers or your model provider. It connects to them. Everything below is marked shipped or planned — we would rather lose a sale than have you find out after signing.
Git hosting — shipped
Any git remote Capybari can authenticate to. Tokens and keys are stored encrypted. Work happens on branches inside your repository, never on a copy in ours.
HTTPS token or SSH key
HTTPS token or SSH key
HTTPS token or SSH key
Self-hosted
Bare remote
Per-task scoping
Deployment targets — shipped
A target is a host reached over SSH, plus four things you write: a deploy path, a deploy command, a health check and a rollback command. Because the commands are yours, the shapes below are configurations rather than separate integrations — which is why there is no waiting list for your stack.
Key generated for you
Deploy command
Deploy command
Deploy command
Migration step
Migration step
Verification
Verification
Automatic on failure
Feeds investigations
Models and agent accounts — shipped
Agents run on large language models. Capybari supplies capacity on every plan and tracks usage per account. On Business you can bring your own provider keys, which means your prompts go to your own account under your own agreement.
All plans
Business plan
Agent profiles
Model and effort
Per agent account
Per plan
Notifications — partly shipped
Email and in-application notification are shipped. Slack, Discord and outbound webhooks are planned for Q3 2026 and are not available today.
Shipped
Shipped
Shipped · SSE
Planned · Q3 2026
Planned · Q3 2026
Planned · Q4 2026
Planned — not available yet
Listed so you can plan around them, not so you can buy them. Nothing in this group works today. Quarters are intentions, not commitments — see the roadmap.
Planned · Q4 2026
Planned · Q3 2026
Planned · Q3 2026
Considering
Considering
Considering
Considering
Considering
Missing something you need? Tell us — the feature request board is genuinely read, and roughly a third of the roadmap started there.
Setting one up
What connecting a server actually involves
Four commands and a key
There is no agent to install on your server and no daemon to run. Capybari generates a key pair, you install the public half, and it connects over SSH like any other client.
- A deploy path — where your code lives on the host.
- A deploy command — whatever you already run by hand today.
- A health check — an HTTP endpoint or a command. Without one, a target can never be marked healthy — which is what makes rollback mean something.
- A rollback command — run automatically when the health check fails.
- A diagnostics command — optional, and the first thing an investigation reads when something breaks.
Extending it
Building your own
Three honest answers about integrating Capybari with something we do not support.
The deploy command is the extension point
Anything you can express as a shell command on your own host is already supported. Most requests we get for a new integration turn out to be a three-line deploy script.
The public API is planned
A documented REST API with webhooks is on the roadmap for Q4 2026. Today's endpoints exist to serve the application and are not stable enough to build against.
Ask before you build
If you are about to write something substantial around Capybari, talk to us first. We would rather shape the roadmap around it than watch you maintain a workaround.
Questions
Before you connect anything
Does Capybari need a GitHub app installed?
No. Capybari works with any git remote it can authenticate to, using a token or SSH key you provide. Native GitHub and GitLab apps are on the roadmap for Q3 2026, but they are a convenience — not a requirement.
Can I deploy somewhere that is not an SSH server?
A deployment target is a host reached over SSH, with a deploy path and commands you write. Because the commands are yours, that covers most things — a systemd service, a Compose stack, a static build, a migration runner.
If your platform has no SSH entry point, Capybari cannot deploy to it today. You can still use it for planning, building and review, and deploy yourself.
Where are my git tokens and SSH keys stored?
Encrypted at rest, scoped to the project that owns them, and never written into an agent's prompt or a task log. The security page sets out the handling in full.
Can I use my own model provider account?
On the Business plan, yes — bring your own keys and your prompts go to your account under your own agreement with that provider. On other plans, capacity is included and metered as agent runs.
What happens if a deployment target stops responding?
The deployment run fails at the phase it reached, your rollback command runs if the failure came after a deploy, and an investigation opens. The target records when its connection was last verified, so a target that has quietly gone stale is visible before you need it.
Do you support monorepos?
Yes. A project can connect several repositories, and a task is scoped to the repository it needs — so a monorepo and a set of separate repositories both work.
Something missing? Ask us or request it.
Connect a repository and see
The free plan connects one repository and needs no card. You can leave the server disconnected until you trust it.
No card required · Deploys to your own infrastructure · Export everything