Looking for an open source Devin alternative?

This guide is written by the people building Shiba

That is an obvious bias, so we will not dress it up. We are not claiming feature parity with Devin or any other product, and this is not a benchmark. We have not run a controlled comparison against Devin, so we make no claims about relative success rates, speed, or cost.

The goal is narrower and more useful: help you decide whether Shiba fits the repository work you actually want to delegate. The repository is published under AGPL-3.0-only, so you can read the implementation, record the revision you evaluated, and connect any reproducible problem to a specific commit. That is the main practical advantage of an inspectable implementation: when something behaves oddly, you can find out why instead of filing a ticket.

One boundary worth stating early. An open-source workspace is not a promise of free execution. It does not hand you model access, it does not make compute free, and it does not turn a managed service into a turnkey self-hosted one. We will come back to what that costs.

What that phrase usually means

Those five requirements overlap, and they are not interchangeable. A tool can match your preferred interface and still be wrong for your access model. Write down which one matters most before you compare anything.

A missing requirement is a reason to investigate, not a reason to assume a workaround exists. If your test suite depends on GPU hardware, a passing remote unit test does not replace running the application on that hardware.

Choose the agent, not just the workspace

Shiba ships an agent catalog. The sandbox image pins each agent CLI, and the orchestrator delegates to whichever one you select, so switching agents is a configuration change rather than a migration.

For an evaluation, start with one agent you already know how to authenticate. Changing the agent, the repository, and the execution environment at the same time makes it very hard to tell which one caused the failure.

Decide where the work actually runs

This is the decision most open-source comparisons skip. Shiba runs the agent inside a Cloudflare Sandbox container on your Cloudflare account. The run clones the repository, edits files, runs commands, and produces a diff. Nothing executes on your laptop, and there is no per-seat subscription to a vendor's servers.

The container is ephemeral per run, and the compute tier is a deploy-time choice from lite up tostandard-4. Larger repositories can move up a tier without a code change.

The trade-off is honest: you are responsible for the Cloudflare resources your runs consume. Set account budgets and alerts. Clearing history does not stop billing, and cancellation is best-effort rather than instantaneous.

A human approves first

Most autonomous engineer tools treat the human as a notification recipient. Shiba treats the human as a gate. Every request, from any surface, becomes a pending approval before anything runs.

Four properties of that gate are worth stating precisely, because they are the difference between a gate and a checkbox.

Where credentials are, and where they are not

This is the part to read twice. No real credential ever enters the container. Egress is intercepted in the Worker, where the real key is swapped in.

• Model traffic. The container holds a dummy key and calls the provider directly. The Worker forwards it through your AI Gateway binding, which injects the stored credential.
• Repository traffic. GITHUB_TOKEN is attached in the Worker, never inside the sandbox.

Outbound traffic is allowlisted before any handler runs. Anything not on the list cannot leave the container, including code the agent pulled from your repository. One exclusion is deliberate:registry.npmjs.org is not allowed in this version. It would enablenpm install inside a run, and it is simultaneously the widest exfiltration channel available. The allowlist is intentionally smaller than your convenience.

The GitHub credential is also scoped per run. github.com defaults to refusal; before a clone, the run scopes the forwarder to the one approved repository path. A request for any other repository gets a 403 with no Authorization header attached. Sibling repositories that share a prefix are refused too. A run that never scoped itself gets no credential at all.

Automations are a gate with nobody standing at it

Scheduled and webhook-triggered work cannot wait for a human who is awake, so it gets the same gate with stricter rules. Three controls apply together.

The optional run_when condition asks a cheap model whether a plain-language precondition holds before the run starts. It fails closed: a model error, an empty answer, or anything not clearly affirmative means no run, and the reason is recorded rather than dropped.

Failures are allowed to look like failures

An agent tool that reports cheerful success when a run actually failed is worse than no tool, because it moves the discovery work to review time. The rules here are blunt.

• A run that fails reports error with the real reason. It is never marked completed on unverified output.
• Results are parsed from a structured envelope, so a failed run cannot render as a successful one.
• A reclaimed run, one whose container disappeared while it was running, goes terminal with an explicit outcome_unknown rather than pretending it finished.
• Output is bounded and redacted for known secret patterns. This is not a guarantee against arbitrary secrets or binary data, so never put secrets in task text or in a repository.

Compare against your actual requirements

Use this table to decide what to inspect. The last point in each card lists evidence to gather, not results we have measured for you.

Run one bounded task before you change anything

Pick a bug or a small improvement you understand well enough to review yourself. Give the agent a reproducible trigger, the expected result, and a boundary around the change. Include the checks that matter, and ask it to explain any check it could not run.

Before approving, confirm the repository and the selected checkout. Run setup and a baseline check first. If the environment cannot install dependencies, fix that before evaluating anything, or you will judge the agent's work against an environment that was already broken.

Then compare the result against the original request, and record four things: setup effort, manual interventions, checks completed, and review time. A successful task should produce an understandable patch and enough evidence for you to decide what to do next.

Increase parallelism only when ownership is clear

Once one task works end to end, try two independent changes. Give each a separate area of responsibility. Different chat conversations already map to different orchestrators, which is the natural isolation boundary, but a Durable Object separates run state rather than architectural disagreement. If both tasks need to change the same contract, settle the contract first, or sequence the dependent work.

Test the integrated result even when the individual branches passed their own checks. For a second opinion, have another session review with a read-only assignment, and keep the writer and reviewer roles clearly separate.

Check recovery as part of the evaluation

Remote work has states that are easy to confuse. A message can be queued without executing. A transcript can stay readable while the compute behind it sleeps. A restored connection does not prove the agent process or the working files recovered.

Run a small disposable task to test this. After a reconnect, inspect the message outcome, the branch, and the current files before submitting the same request again. Keep the client version and workspace configuration with your notes. Reliability matters here because review depends on knowing which commands ran against which files.

Separate software, compute, and model costs

An open-source workspace is not zero-cost execution. Three things can each have a bill.

• Compute — Workers, Durable Objects, and container time on your Cloudflare account.
• Models — inference through your AI Gateway arrangement, or a separate agent subscription if you use one.
• Your time — setup and review, which is usually the largest line item and the one nobody quotes.

Use one representative task to measure the whole workflow, including review time. More parallel tasks increase throughput, and they also increase the number of changes waiting for a person to inspect. That queue is a real cost with a real failure mode.

What is deliberately not here yet

Honesty about limits is more useful than a feature list. Today:

• Each installation is single-tenant and account-owned. There is no multi-tenant isolation.
• npm install inside a run is not possible, by design.
• Cancellation is best-effort.
• The Worker checks for a Cloudflare Access header; that is not JWT verification. Keep the route behind Access and do not expose the origin.
• Sessions resume and stop/resume are not implemented. They are a real architecture change, not a toggle.

When Shiba is worth evaluating

Evaluate Shiba when you want an AI software engineer that runs inside your own cloud account, that a human approves before anything executes, and whose code you can read. It fits well if you already run Cloudflare, if you need a per-repository credential boundary, and if you want agent choice without rebuilding the harness layer yourself.

Look elsewhere if your deciding requirement is a specific third-party integration, a managed hosting arrangement you do not want to operate, or byte-for-byte identical behavior with a different tool. An alternative can serve the same goal without being a drop-in replacement, and we would rather you find the right tool than ours.