OpenRelease AI

OpenRelease AI reviews your software before publication and detects potential errors using artificial intelligence.

Comment

Inspiration

A deployment can appear successful because a command returned exit code 0, while the application is still unhealthy, unreachable, or incorrectly configured.

We built OpenRelease AI to create a more trustworthy release process: one that does not stop after deployment, but observes the real runtime state, explains failures with evidence, applies only authorized repairs, and verifies that the application is actually working.

What it does

OpenRelease AI analyzes a local repository or an allowlisted Git URL and creates a validated release plan.

It can:

  • Detect project structure, frameworks, build commands, ports, health routes, Dockerfiles, and Kubernetes manifests.
  • Build and test the application.
  • Scan the container image.
  • Deploy to Docker or an isolated non-production Kubernetes environment.
  • Collect logs, events, rollout status, readiness results, restart information, and HTTP health responses.
  • Diagnose failures using collected evidence.
  • Apply minimal and reversible repairs through Codex.
  • Rebuild, redeploy, and verify the application again.
  • Generate an audit trail, code diff, rollback data, final report, and cleanup evidence.

OpenRelease AI only reports success after all mandatory verification criteria pass.

The repository includes a demonstration application with two intentional failures: a broken Dockerfile instruction and an incorrect Kubernetes readiness path. OpenRelease must detect and repair both before the demo succeeds.

How we built it

We built OpenRelease AI as a TypeScript monorepo managed with Nx.

The main components are:

  • A NestJS API.
  • A BullMQ worker backed by Redis.
  • PostgreSQL for durable execution state and audit records.
  • Zod schemas for validating API data, release plans, model output, and deployment results.
  • Docker and Kubernetes providers.
  • Trivy for image vulnerability scanning.
  • A React web console and guided CLI.
  • Codex CLI and GPT-5.6 for planning, diagnosis, and constrained repair proposals.

We used Codex as a pair-programming assistant for much of the project. It helped us create typed contracts, provider adapters, test fixtures, CLI and web integrations, documentation, and small reviewable patches.

However, model output is never trusted as proof of success. Policies, command execution, repair permissions, state transitions, retries, verification, rollback, and cleanup remain controlled by deterministic software.

Challenges we ran into

One of the hardest challenges was safely handling model output. An AI model can return invalid data, suggest unsupported commands, modify unrelated files, or incorrectly conclude that a deployment succeeded.

We addressed this with strict Zod schemas, bounded repair attempts, file allowlists, exact patch preconditions, isolated workspaces, timeouts, secret redaction, and deterministic verification.

Another challenge was handling untrusted repositories. Package scripts, Dockerfiles, manifests, logs, and model responses all had to be treated as potentially unsafe.

We also had to preserve execution state across asynchronous jobs and distinguish between a workflow that merely completed and a release that was actually healthy.

Accomplishments that we're proud of

We are proud of building a complete release loop instead of a simple deployment script.

OpenRelease AI can move through repository analysis, planning, build, testing, scanning, deployment, observation, diagnosis, repair, redeployment, verification, reporting, and cleanup.

We are also proud of the evidence-based demo. It does not pass by displaying a simulated success message. The real workflow must observe both intentional failures, repair them, verify Kubernetes readiness and HTTP health, generate the report and diff, and clean up its resources.

Users can see what happened, why it happened, what changed, and which verification criteria passed or failed.

What we learned

We learned that autonomous infrastructure requires deterministic boundaries around probabilistic reasoning.

AI is useful for interpreting logs, understanding repositories, generating hypotheses, and proposing repairs. But security policies, process execution, verification, rollback, and state transitions must remain controlled by traditional software.

We also learned that observations, hypotheses, diagnoses, repairs, and verification results should be stored separately. This makes the system easier to audit and prevents an AI-generated explanation from being treated as verified truth.

What's next for OpenRelease AI

Next, we plan to add:

  • Better environment preflight checks.
  • More application repair scenarios.
  • Improved retry and circuit-breaker behavior.
  • Durable dead-letter queue recovery.
  • Additional deployment providers and project types.
  • Richer visual evidence and diff review.
  • Human approval workflows for higher-risk repairs.
  • Broader infrastructure verification and rollback support.

Our long-term goal is to make OpenRelease AI a trustworthy autonomous release engineer that helps teams move from source code to a verified deployment with clear evidence, controlled repairs, and measurable success criteria.

Built With

Share this project:

Updates