Turn tickets into
local AI execution pipelines.
Ingest tickets from GitHub or Jira, send them through AI steps like Playwright repro, create failing test, and fix failing test, then let workers run the whole flow on your machines in Docker.
→ true
→ true
→ true
The workflow layer between your tickets and local workers.
Boboddy is built for the path from inbound ticket to executed fix. Ingest the work, pass it through AI steps, and keep the execution on infrastructure you control.
Start from real tickets
Pull work in from GitHub, Jira, or another source system so your pipelines begin with the same tickets your team already uses.
Chain purpose-built AI steps
Model each stage of the workflow explicitly — reproduce with Playwright, create a failing test, fix the failing test, then decide what should happen next.
Run workers anywhere
Spin up workers on a laptop, a server, or a fleet. They claim pipeline work, run each step in Docker, and report results back over a single connection.
Bring your own AI
Use the model that fits each step. API keys stay with your workers, so the control plane coordinates the workflow without owning your credentials.
Per-step sandboxes
Every pipeline step gets a fresh Docker container with a scoped agent. Filesystem changes, secrets, and tool access stay isolated by default.
See the workflow advance
Live execution feeds, structured signals, and per-step traces show exactly why a ticket advanced from ingest to repro to test creation to fix.
A simple model for a real ticket workflow.
Ingest the ticket, move it through AI steps, and let your workers execute the flow. The shape stays simple even when the workflow gets powerful.
Ingest the ticket
Start with the work item your team already has. Pull a GitHub issue or Jira ticket into a pipeline-ready shape with the context your downstream steps need.
import { defineStep, z } from "@boboddy/sdk";
export const ingestTicket = defineStep({
name: "ingest-ticket",
input: z.object({ source: z.enum(["github", "jira"]), ticketId: z.string() }),
output: z.object({ title: z.string(), repo: z.string(), acceptanceCriteria: z.array(z.string()) }),
signals: {
ticketReady: { type: "boolean" },
priority: { type: "string" },
},
});Send it through AI steps
Compose the concrete workflow you want to automate. For example: Playwright tester, create failing test, then fix failing test.
import { definePipeline } from "@boboddy/sdk";
import { ingestTicket, playwrightTester, createFailingTest, fixFailingTest } from "./steps";
export const ticketToFix = definePipeline({
name: "ticket-to-fix",
stages: [
{ step: ingestTicket, advanceWhen: "ticketReady == true" },
{ step: playwrightTester, advanceWhen: "reproduced == true" },
{ step: createFailingTest, advanceWhen: "testCreated == true" },
{ step: fixFailingTest, advanceWhen: "testsPassing == true" },
],
});Run workers on your machines
Workers connect to your project, claim steps from the pipeline, run them in Docker, and stream the results back from your own hardware.
# on any machine you own
$ boboddy auth login
$ boboddy work my-project
→ worker-01.local connected
→ claimed: create-failing-test · exec_8f3a
→ docker: pulling agent image
→ signal: testCreated = true
→ next: fix-failing-testSelf-hosted by default. No compromise.
Boboddy ships the control plane. You bring the workers. The result is a platform with the polish of a SaaS and the trust boundary of on-prem.
Your code never leaves your network
Workers clone, run, and report from inside your perimeter. Source, build artifacts, and intermediate state stay on your hardware.
Your AI provider, your API keys
Credentials live on the worker, not the control plane. Swap providers per project or per step without giving up keys to anyone.
Docker isolation per execution
Each step run is sandboxed in a fresh container with a scoped agent. Nothing leaks between executions — by design.
Pay for compute you already own
Shared execution planes charge for cycles you don't need. Boboddy runs on the machines you have, at the cost you already pay.
Run ticket-to-fix workflows without rebuilding the control plane.
Keep the look and polish of a hosted control plane while running the real work — from ticket ingest to failing test to fix — on machines you already control.