Shipfox

Ways to automate engineering work

Compare how local coding agents, agent automations, CI platforms, and Shipfox run and coordinate engineering work.

What sets Shipfox apart

Agents follow your process

Agents run as steps in your workflow and only use the tools you allow.

Each workflow is a file in your repository. Changes go through code review, so your whole team uses the same process. A workflow mixes agent steps with normal commands, which are fast and give the same result every time. It can repeat a step until your checks pass, or wait for a review comment and continue with the earlier context. You set the checks and approvals, as strict or as light as you want. Each agent gets only the access it needs, never a personal account.

Open source, no lock-in

Pick any model for each step, and run on our cloud or your own.

Use a low-cost model for simple work, and a stronger model only when you need it. You see the cost of each run. Shipfox is MIT licensed and self-hostable, so you can move your workflows to another system at any time.

Gets better every week

Workflows watch your other runs, find what breaks, and suggest a fix.

Every run keeps a full log and its cost. A workflow can start when another run fails, read its logs, and report the cause. Your coding agent reads the same runs through Shipfox and proposes changes to your workflows, such as a fix or a different model for a step. You review each change as a pull request.

100+ integrations

Start a workflow from your tools, and let agents use them.

A workflow can start from many sources: a ticket, an alert, a chat message, a failed check, or a schedule. During the workflow, agents can read and write in your other tools, and you give this access one step at a time. Shipfox is not limited to where you store your code. You can connect a new tool in a few minutes.

Detailed comparison

Swipe to compare.

Compare approaches to engineering work
Comparison pointLocal coding agentAgent automationsCI platformShipfox
Example providers
Products
Running work
Where code runsEngineer's machineProvider-managed cloud runnerHosted or self-hosted runners
Execution environmentNo runner choicePreset runner environmentCustom runners, images, and network
Parallel workNo managed parallel jobsParallel managed runsParallel jobs within runner capacityParallel jobs by default
TriggersHuman starts a sessionProvider-supported events and schedulesRepository events, schedules, and webhooks
Coordinating agents and steps
Later review commentsEngineer follows up in chatNew automation runNew workflow run
Failed check needs a code fixEngineer prompts another attemptNo independent feedback gateChecks fail jobs; no built-in agent repair
Agent and fixed steps in one flowNo workflow orchestrationNo built-in mixed-step workflowAgent call needs job scripting
Agent conversation across stepsNo shared workflow sessionNo cross-run agent sessionNo native agent session across jobs
Team control
Shared team processNo shared run processReusable saved automationsShared jobs and workflowsShared workflow definitions
Configuration in codeNo versioned workflow definitionUsually configured in provider UIWorkflow files in the repoWorkflow YAML in the repo
Model choiceAgent's supported modelsProvider-supported modelsChosen in the agent call
Agent-ready external toolsEngineer adds MCP serversSmall native action set; MCP for moreAgent tools need custom wiring
Tool credentials and scopePersonal credentialsMCP often uses personal OAuth and grants all server toolsSecrets passed to jobs
Visibility and cost
Activity logsNo shared run historyAutomation session logsWorkflow and job logs
Model cost by taskNo shared cost per taskUsage in provider accountModel cost separate from runner usage
Was this page helpful?
Edit this page on GitHub