This is the closest real competitor, so it deserves the most careful page. Both are open source, both self-host, both run fully autonomously rather than only interactively. The difference is not whether they can do the job. It is shape: one pipeline you extend, or a suite of workflows that ships assembled.
Last Light is not uniquely "the self-hosted autonomous one". OpenHands got there first and is the bigger project by every measure that counts: more users, more integrations, a larger community, and a cloud option if you ever want to stop self-hosting.
Its Resolver does exactly the event-driven thing. Label an issue, and a sandboxed runtime spins up, edits code, runs tests, and opens a pull request. That is the same loop as Last Light's build line. If that loop is your requirement, OpenHands is the more proven and lower-effort path, and this page is not going to pretend otherwise.
Where Last Light differs is coverage. It is not one pipeline: it is a triage sweep, a PR reviewer, a build cycle, a weekly security pass, a health report and a Slack chat surface, all as YAML on one engine, with a hardened network boundary as the default posture rather than something you assemble.
| Last Light | OpenHands | |
|---|---|---|
| Licence | MIT, free | Open source, free |
| Hosting | Self-hosted only | Self-hosted, or OpenHands Cloud / Enterprise |
| Model choice | BYO across providers | Full BYOM |
| Autonomous trigger | Many webhook types, Slack, cron sweeps, CLI | Issue label via Resolver, or headless mode |
| Built-in workflows | Triage, review, build, security, health, explore, verify, chat | One issue→PR pipeline you extend |
| Isolation | Docker / micro-VM sandbox, default-deny egress firewall | Sandboxed runtime |
| Token scoping | Four downscoped per-run App token profiles | Standard token |
| Approval gates | Mid-run, wired to GitHub, Slack and dashboard | In the loop, or review the PR |
| Interactive use | None. It is a service, not a pair programmer | Yes, CLI and IDE |
| Ecosystem | Small and young | Large, mature, well known |
your need is "label an issue, get a PR, self-hosted", or you want one agent that works both at your desk and in automation. It is the more proven, lower-effort path, and a bigger project to bet on.
you want the whole repo-maintenance suite as one purpose-built service rather than something you compose, and you want the sandbox, egress policy and token scoping to be the default posture rather than your integration work.
If you like the philosophy of one, evaluate the other. These are adjacent projects solving overlapping problems, and OpenHands has the longer track record.