How VibeNest Built a Self-Healing Deployment Platform

Building an application is faster than it used to be. Getting that application online, understanding why it failed, and keeping it healthy are still separate problems.

VibeNest is being built around that gap. It takes a GitHub repository, determines what is inside it, prepares the application for deployment, observes the real running container, and applies bounded fixes when supported failures occur.

That makes it more than a build button. The goal is a self-healing deployment platform that can handle common operational work for the person who created the application.

150 days of engineering · 638 commits · ≈145,000 handwritten lines · 2,770 tests in the latest green run

What Automated Deployment Means in VibeNest

Deployment automation normally means moving code through build and release stages without executing every step manually. That is useful, but it assumes the repository already describes a valid deployment path.

Many small applications and vibe-coded apps do not start there. The code may work locally while the repository is missing a production start command, the correct internal port, environment-variable documentation, database provisioning, or a container configuration.

VibeNest treats repository understanding as part of automated deployment.

The current path is:

GitHub repository
→ repository and service analysis
→ runtime, port, database, and environment detection
→ build and deployment
→ real-container monitoring
→ bounded diagnosis and recovery
→ live application

This is the difference between automatically running a pipeline and helping create a viable pipeline from an imperfect repository.

From GitHub Repository to Deployment Plan

The first step is not building the image. It is understanding what needs to be built.

VibeNest analyzes the repository and looks for application boundaries, runtimes, manifests, ports, databases, and configuration requirements. For monorepos, it can identify multiple services instead of treating the entire repository as one application.

That information becomes a deployment plan.

Service and runtime detection

Repository analysis identifies supported services and the runtime each service requires. This is especially useful when an AI coding tool produced a repository with a frontend, API, worker, or multiple nested applications.

Database detection before the first build

If the project requires PostgreSQL or SQLite, VibeNest prepares the appropriate path before the application reaches its first runtime failure.

Database tooling continues after deployment. A project owner can open the database console from the dashboard, inspect tables, run queries, and export results without exposing a private database or setting up SSH and port forwarding.

Related: Database Console

Environment-variable discovery

VibeNest combines repository hints such as .env.example with runtime evidence. Missing required variables can be shown by name while values already configured or supplied by the platform are excluded.

This turns a vague crash into an actionable configuration step.

Recovery Instead of Blind Redeployment

A failed build does not automatically mean the project needs another identical build.

VibeNest collects deployment logs, application state, repository evidence, and host/container signals. AI Doctor uses that evidence to diagnose supported failures and propose or apply a bounded correction.

Examples include:

• correcting a supported internal-port mismatch;
• identifying missing environment variables;
• preparing a Dockerfile for a simple static project;
• repairing supported private-repository deployment configuration;
• distinguishing an active long build from a stalled deployment;
• identifying a real out-of-memory failure from host evidence.

Automation has limits. VibeNest does not repeatedly mutate a repository until something happens to work. Supported automatic corrections have attempt limits and evidence requirements. When owner input is needed, the platform stops and gives a concrete next step.

This bounded behavior is what makes the system closer to self-healing infrastructure than a blind retry loop: detect the actual state, diagnose the failure, recover when the correction is safe, and escalate when it is not.

Application Monitoring Must Observe the Real Application

Recovery is only useful when monitoring sees the actual system.

VibeNest checks the real container through the correct infrastructure path instead of treating a temporary platform status page as the application. Host-level monitoring supplies memory, CPU, container state, and OOM evidence.

This matters because a public URL can be guarded while an application starts or recovers. Monitoring the guard page would produce a false failure signal. Monitoring the container provides the evidence needed for accurate application monitoring and recovery.

The platform also handles unstable containers more carefully. Repeated flapping settles into one meaningful crash-loop diagnosis instead of alternating between contradictory online and failed alerts.

Related: Automated Deployments, Real Monitoring, and Better AI Pages

The Engineering Surface Behind the Workflow

The deployment path touches repository analysis, build orchestration, billing, monitoring, backups, database tooling, analytics, public pages, and multiple external systems.

The current VibeNest codebase includes approximately:

• 145,000 handwritten lines across platform logic, Blazor/Razor UI, and tests;
• 137 services and 97 interfaces;
• 26 background workers;
• 62 entities and 101 database migrations;
• 103 pages and 184 Blazor components;
• 2,770 tests in the latest complete green run across 179 test classes.

Generated Entity Framework migration code and compiled Tailwind output are excluded from the handwritten-code headline.

The ratio is also deliberate: for every approximately 1.5 lines of C# platform logic, there is one line of test code.

Technology Map

The core application uses .NET 10, Blazor, .NET Aspire, and YARP. PostgreSQL and ClickHouse cover transactional and analytical data. Coolify and Docker provide the deployment substrate.

The wider system connects to GitHub, OpenRouter, Paddle, Resend, Google OAuth, WebAuthn, DataForSEO, S3-compatible backups, and Telegram.

Each integration exists to remove a separate setup burden from the application owner: source access, AI analysis, billing, transactional email, identity, search data, backup storage, or notifications.

What Comes Next

The most useful next step is not adding more automation for its own sake. It is improving the places where real projects still require unnecessary manual intervention.

Current areas worth examining publicly include deployment logs, environment-variable setup, database tools, and application analytics.

You can help set the order. Vote on what the platform should build next on the public roadmap.

If you have a GitHub project or vibe-coded app that works locally but is difficult to deploy, send the repository or demo. Real deployment cases are the best way to decide what the platform should automate next.

Frequently Asked Questions

What is automated deployment?

Automated deployment uses software to move an application from source code to a running environment without manually executing every build and release step. VibeNest extends this by analyzing repository requirements and diagnosing supported failures.

Can VibeNest deploy from GitHub?

Yes. VibeNest analyzes a GitHub repository, detects supported services and configuration requirements, prepares the deployment, and monitors the resulting application.

What happens when a deployment fails?

VibeNest collects repository, log, runtime, and container evidence. AI Doctor diagnoses supported failures and can apply bounded corrections. If the issue requires a secret, decision, or unsupported change, the platform asks the owner for input.

Does VibeNest support monorepos?

Repository analysis can detect multiple supported services inside a monorepo and prepare separate application boundaries where appropriate.

Is every deployment failure fixed automatically?

No. Automatic recovery is intentionally limited to supported corrections with sufficient evidence and attempt limits. Unsupported or sensitive changes require owner input.