Orbinx

Coolify deployment fails. Orbinx diagnoses it, writes a fix with Codex and GPT-5.6 in an isolated E2B sandbox, and opens a pull request for you to review. It never merges on its own

Comment

Inspiration

I build and deploy projects on VPS infrastructure, and I know the feeling of a deployment failing for a small reason that still takes twenty minutes to trace: a renamed API field, a broken import, a missing environment variable. Each time, I'd end up jumping between Coolify, logs, GitHub, and a terminal, trying to answer the same handful of questions, what changed, which service is affected, whether the fix is safe enough to automate, and where the actual pull request is once something gets proposed.

Orbinx started as an attempt to keep those answers in one place: a deployment and uptime console for Coolify-based infrastructure, with a narrow, reviewable path for automated repairs.

What it does

Orbinx connects to your Coolify environments, discovers the servers and resources behind them, and watches the public URLs. Infrastructure health, uptime history, incidents, and server status all live in one dashboard.

When a deployment fails, Orbinx opens an incident with redacted evidence and a diagnosis. For a narrow set of build and import failures it's been given policy to handle, it can go further and attempt a repair:

Deployment signal
→ incident and diagnosis
→ policy check
→ isolated E2B sandbox
→ Codex inspects and edits the repository
→ Orbinx validates the diff
→ static verification
→ GitHub pull request
→ human review and merge

The repair system stays inside hard boundaries: one configured repository, one branch, one source-file scope. Lockfiles, package manifests, Dockerfiles, workflows, migrations, credentials, and production infrastructure are all off-limits, and nothing here pushes to main, merges its own pull request, or restarts a production service.

What judges see in the hosted submission is a read-only replay of a real end-to-end run, the incident, the agent's actual activity, the constrained diff, the verification output, and the resulting GitHub pull request, without exposing the E2B, provider, or GitHub credentials behind it.

How I built it

Orbinx is a TypeScript monorepo: a Next.js dashboard, PostgreSQL with Drizzle ORM, and Redis-backed workers running on BullMQ, talking to Coolify through its API.

The dashboard handles the operational side, connecting multiple Coolify instances and refreshing inventory, server and resource views, HTTP uptime monitors with response-time history, incident triage with redacted evidence, Discord notification status, and a repair drawer with a full replayable activity timeline, diff view, and pull request handoff. The worker side runs the monitoring checks, ingests events, orchestrates diagnosis, delivers Discord notifications, and executes repairs once they clear policy.

For Tier 2, E2B provides the isolated execution environment. Orbinx clones the configured repository into a sandbox, runs Codex against a constrained instruction, and only opens a GitHub pull request once the resulting diff has passed both policy validation and the configured verification command.

Codex and GPT-5.6 were my main implementation partner for most of the hackathon, they built the Tier 1 dashboard on top of an existing backend, the monitoring and incident experience, the Tier 2 repair workflow, the E2B integration, and a lot of the tests, docs, and UI iteration along the way. My part was the product decisions: setting the safety limits, reviewing every change, running the end-to-end test myself, and deciding exactly what the hosted demo could honestly claim.

The replay deployment runs on Coolify, with its own PostgreSQL and Redis, a migration step, an idempotent seed job that loads the sanitized recorded repair, and a read-only reviewer access gate.

Challenges I ran into

Getting an agent to edit a file correctly wasn't the hard part. Making the whole path safe, observable, and honest, that took most of the effort.

Sandbox setup was the first real snag. Different repositories need different runtimes, package managers, and verification commands, so rather than let a model invent its own setup steps, I built the architecture around reviewed runtime profiles and used a Node and pnpm fixture for this demo.

Agent traces needed just as much care. Showing an agent's hidden reasoning would be misleading and honestly a little unsafe, so Orbinx records observable activity instead: sandbox creation, repository clone, files inspected, commands run, edits made, warnings, and verification status. Secrets, raw prompts, private reasoning, and unbounded logs never make it into the dashboard.

The last piece was giving judges a hosted demo without triggering real API spend or handing a public deployment write access to a real repository. The answer was a clearly labeled replay of an actual run: the real diff, the real verification result, the real activity trace, and the real GitHub pull request, presented plainly as a replay, never as a live repair.

Accomplishments that I'm proud of

A few things I'm genuinely proud of:

  • I built a complete operational UI — incidents, uptime, infrastructure, monitors, settings, and repair review — during the hackathon window, not before it.
  • I ran a real, private, end-to-end repair: Codex inspected the fixture repository in E2B, made the constrained TypeScript fix, passed static verification, and Orbinx opened a real GitHub pull request for review.
  • That proof is public: Ops Console pull request #2.
  • The repair policy is enforced after the agent returns a diff — a prompt alone never grants permission to touch a file.
  • The recorded replay lets judges inspect the same evidence I used during development, without needing my credentials.

What I learned

Autonomous coding workflows need real operational boundaries. A repair system earns trust from its policy long before it earns trust from a clever prompt.

Most of the actual product value turned out to live in the evidence around a run: the diagnosis, the allowed scope, the file diff, the verification result, the pull request, the explicit human handoff. That's what lets someone review a proposed fix on its own terms, rather than just trusting whatever the agent says happened.

What's next for Orbinx

I plan to continue Orbinx as an open-source project. Next up:

  • A GitHub App flow with repository installation, narrower permissions, richer pull request metadata, and check-run reporting.
  • Reviewed runtime profiles for Node, Python, Go, Rust, containers, and CI environments.
  • Broader operational metrics: latency percentiles, SLOs, incident trends, deployment-to-health correlation, and reporting.
  • More alerting channels, escalation rules, maintenance windows, and team access controls.
  • Wider repair categories, only once verification and review controls are strong enough to support them.
  • Database migrations, credentials, IAM, production infrastructure, merges, and production restarts stay outside autonomous mutation scope, permanently.

Orbinx will keep its core rule: an agent may propose a repair, but a human remains responsible for approving and deploying it.

Built With

Share this project:

Updates