Self-hosted Devin alternative

Support update, 14 October 2026: Native enforcement and login modes are restricted. Linux enforcement remains unverified; all Claude stages temporarily refuse. Select Codex or Pi. See current versions, prerequisites and protection limits.

Devin is Cognition’s coding agent, sold as a product with its own plans, cloud agents and model access; its pricing page offers “Deploy in your virtual private cloud (VPC)” on Enterprise only. Provefab is a service that runs on your own Mac or Linux server and drives the coding agents you already pay for (Claude Code, Codex or Pi), signed in with your own plans or your own API keys. It takes labelled GitHub issues, and Jira Cloud and Linear tickets in beta, and opens pull requests on GitHub only. If you want ticket-to-pull-request on a machine you control, with agents you already use, this page sets out the difference as fairly as we can. We describe Devin only from its own pricing page and documentation, as read on 2026-10-06.

Side by side

Where the work runs

Devin’s pricing page lists “Access to cloud agents (Devin Cloud)” on Pro and above, and “Deploy in your virtual private cloud (VPC)” only in the Enterprise column. It also mentions Devin Desktop and a CLI. We did not find a page describing a ticket integration that runs on your own machine outside Enterprise, so we do not claim one either way.

Provefab is a single binary that runs as a launchd agent on macOS or a systemd user service on Linux (operations). The agents run on that machine, as your account, in a separate worktree per task. Your code, your sign-ins and the record of each change stay there. If you want it on a server, the Linux server guide walks through the sign-ins, the service and lingering.

How a ticket becomes a pull request

In Linear, Devin’s documentation says to “Assign the ticket to Devin directly in Linear”, to add a playbook label (“e.g. !plan, !implement, !triage, !review”), or to “Mention Devin in a ticket comment with specific instructions.” For Jira, the Jira docs describe a Rovo agent or a service user: assign the work item, add the devin label, or @mention it, and they state “Jira Cloud. Devin for Jira is a Forge app”. Devin’s pricing page lists GitHub, GitLab and Bitbucket.

Provefab works from one label. On GitHub, someone who can triage the repository puts provefab on an issue; on Jira Cloud or Linear, whoever can label the ticket puts the repository’s label on it. Provefab picks it up at its next poll. It plans with read-only tools, implements in a worktree, runs your checks, has another model review, then commits, pushes and opens the pull request itself. For Jira and Linear, the branch and the pull request title carry the ticket key so their GitHub integrations link the two, and Provefab never changes a ticket’s status. The code, the branches and the pull requests stay on GitHub. Jira and Linear support is beta: “tested against recorded API responses, not yet against live Jira and Linear sites” (Jira and Linear). The Jira and Linear guide shows the setup end to end.

What you pay for

Devin is priced by plan, with a usage allowance per paid plan; see the current numbers on its pricing page. Its FAQ says “Each paid plan comes with a usage allowance that refreshes automatically on a daily and weekly basis” and that extra usage “is consumed at API pricing.”

Provefab’s core is free under the Functional Source License. Provefab Pro, EUR 79 per month per GitHub organization, adds a second reviewer on another model, merge policies, cost reports, reviewer calibration and rule proposals (pricing). With the core or Pro, you pay the model vendors directly: Provefab does not resell model access, it runs the agents on your own plan logins or API keys, and it routes each stage to the cheapest model that can do it, your plans first, then your API keys by price. Choose a supported login mode from the current native policy guide, and check your provider’s terms for your intended use separately.

What has to pass before you look

We do not know how Devin checks its work beyond what its pages say, so we only describe Provefab here.

• Your checks decide. Your repository’s commands (format, lint, tests) run in Provefab’s own code, not the agent’s; a failure goes back to the agent.
• A bug needs a reproduction. For a bugfix, the plan must give a command that fails before the fix. If it already passes, Provefab stops.
• Another provider reviews. The reviewer comes from a different model provider than the implementer whenever your catalog has one: a Claude change is reviewed by an OpenAI model, and the other way round.
• Agents cannot push. Every tool call goes through a guard, agents have no push credentials, and only Provefab commits and pushes.
• The pull request carries its evidence. It lists the checks that ran and any test the change deletes or disables, then waits for a person. The free core never merges.

When Devin is the better choice

Devin is the better pick in several real cases:

• You do not want to run a machine. Provefab needs a Mac or a Linux server that stays on. Devin offers cloud agents.
• Your code is on GitLab or Bitbucket. Devin’s pricing page lists both. Provefab opens pull requests on GitHub only.
• You want Devin’s tracker flow. Assigning a Linear ticket, playbook labels and comment mentions are richer than a single label, and Devin’s Jira and Linear integrations are not marked beta on the pages we read.
• You want one vendor. One plan, one product, one support team for the agent and the model access, instead of signing in Claude Code or Codex yourself and running Provefab next to them.
• You want to start work from chat. Devin’s pricing page lists Slack and Teams integrations. Provefab starts from a label on your tracker, or from provefab add <issue-url> in a terminal.

What Provefab does not do

• It hosts nothing. You keep a Mac or Linux server running.
• It opens pull requests on GitHub only: no GitLab merge requests, no Bitbucket.
• It supports Jira Cloud, not Jira Data Center, and polls instead of using webhooks.
• Jira and Linear support is beta.
• It has no web app: it is a CLI and a background service, and it talks to you in comments and labels.
• Native command restrictions supplement the guard. Secret protection uses a deny list, and validation dependencies need explicit protected paths. This is not a VM or container boundary (security).
• It does not see your GitHub CI.

Try it on one repository

Install it with curl -fsSL https://provefab.com/install.sh | sh, sign in with provefab login codex, then run provefab init, provefab repos add <owner/name>, provefab doctor and provefab run --dry-run, which classifies and routes open issues without changing anything. Or point a coding agent at Set up with a coding agent. Then label one issue and read the pull request it opens. For tickets, follow the Jira and Linear guide; for a server, the Linux server guide. If you are also weighing a local, open-source tool, see no_human compared.