Hi all! I built fly-swe, a small always-on service that watches a GitHub repo. When an issue gets labeled bug, docs or chore, it runs mini-swe-agent against the code and opens a PR, with a “How I tested” section the harness verified itself.
The Fly part:
- One shared-cpu-1x Machine (1 GB) with
auto_stop_machines = "off", plus a 1 GB volume (~$6/mo) - Web + worker in the same Machine via
honcho/Procfile - SQLite (WAL) queue on the volume, with idempotent deliveries and orphan recovery after restarts
- Runtimes the target repo needs (e.g. Node) are downloaded on demand into
/data/toolson the volume and reused across tasks, so the image stays Python-only - Secrets via
fly secrets set; deploys run from a GitHub Release with a smoke test
On a real TypeScript monorepo, the last 10 issues cost a median of ~$0.31 of LLM each (mostly GLM-5.3), and every PR was reviewed by a human. fly-swe never merges.
Write-up with the design decisions (why the LLM never touches git, the three budget caps, re-running the agent’s tests): Running an issue-fixing agent on a $6 Fly Machine: a queue, three budgets, and an honest test report - DEV Community
Repo + 10-minute quickstart: GitHub - stateway-io/fly-swe: A lightweight agent that resolves your GitHub issues — built on mini-swe-agent, model-agnostic, and deployable in about ten minutes. · GitHub
Next on the roadmap is a per-task sandbox, and I’m looking at ephemeral Machines/Sprites for it. Ideas and feedback very welcome!