Automated Deployments, Real Monitoring, and Better AI Pages

Over the last few weeks, we improved three parts of the VibeNest experience that meet at the same goal: getting an application online and keeping it useful without constant manual intervention.

Deployments now recover from more common failures, monitoring observes the real container instead of a platform status page, and Beautify can generate complete responsive pages without changing the language of the source content.

More Automated Deployment Recovery

AI Doctor no longer waits indefinitely for someone to click Apply when it has a safe, actionable fix. Supported corrections can now be applied automatically, with limits that prevent repeated attempts from becoming a redeploy loop.

This includes fixes such as correcting an internal port or adjusting a supported deployment setting. When VibeNest cannot solve the issue safely, it stops and gives the owner a concrete next step instead of guessing.

Missing environment variables are now visible

If an application crashes because a required secret such as BOT_TOKEN is missing, the diagnosis card can list the specific variables that need values.

VibeNest combines signals from the repository's .env.example file and the runtime error, excludes variables already configured, and ignores infrastructure values supplied automatically. The Open Settings action now goes directly to the Environment tab.

Private repositories deploy correctly

Private GitHub repositories can now use the same project flow as public repositories. After the VibeNest GitHub account is added as a collaborator, the platform prepares an authenticated fork that Coolify can clone securely.

We also fixed a repository URL mismatch in the Coolify API. Coolify expects different formats when creating and updating an application; VibeNest now sends the correct form for each operation.

Private-repository detection runs on every deployment, not only during project creation. Projects left in a broken state by the earlier behavior can repair themselves on the next deploy.

Better defaults before the build starts

VibeNest now detects the application port from repository manifests, including Docker EXPOSE and PORT declarations, before deployment begins. Routing can be configured correctly from the start instead of discovering the mismatch only after the image is built.

Simple static HTML projects also receive a working Dockerfile automatically, removing another case that previously ended with a manual-fix message.

Heavy builds get time to finish

The old queue timeout used a flat wall-clock limit. That could mark a large machine-learning or Playwright build as failed while it was still producing output.

The deployment monitor now checks whether the build log is moving. An active build is allowed to continue; only a genuinely stalled deployment is treated as stuck.

Containers that repeatedly restart also stop being mislabeled as Building. VibeNest detects a crash loop even when Coolify does not provide a clean restart counter and shows a useful runtime diagnosis instead of suggesting another blind redeploy.

Application Monitoring That Sees the Real App

Reliable application monitoring depends on observing the container itself. We found a loop where VibeNest was checking its own temporary 503 page instead.

When a project was not marked Running, the public URL showed a controlled status page. The monitor checked that same URL, interpreted the platform's 503 as an application failure, and kept the project locked in crash_loop even when the container was healthy.

Health checks now connect directly to the correct Coolify edge server with the project's host name. They see the real application response while the public status guard continues protecting visitors from incomplete deployments.

Live host and container monitoring

The host metrics agent is now running correctly across active servers and reports container memory and CPU usage. This gives VibeNest real signals for diagnosis instead of relying only on application logs.

The installer had been losing one final newline while generating its systemd unit. That small formatting error prevented the script from enabling or starting the service. The installer and generated agent templates are now tested together to prevent them from drifting apart again.

Real OOM detection

A Linux out-of-memory kill often ends a process with SIGKILL, leaving no useful application error. Coolify may also omit the exit details needed to distinguish an OOM event from an ordinary crash.

The host agent now reads Docker's OOMKilled state and exit code 137 directly. VibeNest records a real oom_failed result when the host confirms memory exhaustion and avoids repeatedly deploying the same container.

The evidence works both ways: a low-memory container is no longer labeled as memory-starved simply because it stopped without a log.

Fewer contradictory alerts

Flapping containers previously produced alternating online and failed notifications as different monitoring passes observed different moments of the restart cycle.

After repeated flaps, the monitor now settles the project into a crash_loop state and emits one useful alert instead of changing its verdict on every pass.

Beautify Generates Real Responsive Pages

Beautify can now produce visually complete, responsive project pages while preserving the language of the original content.

The AI was already generating much of this work, but the sanitization pipeline removed important pieces before they reached the browser. We fixed the full path from generation to rendering.

Your content stays in its original language

An old design prompt explicitly requested a Russian response, so English projects could receive Russian headings and calls to action after beautification.

Beautify and SEO generation now preserve the language of the source Markdown. The feature improves presentation without translating the project into a different language.

Real CSS instead of inline styles only

Beautified pages can now include a dedicated <style> block with classes, responsive media queries, hover states, animations, gradients, and reusable design tokens.

Generated CSS is automatically scoped under .beautified-content. It can style the project page without leaking into the VibeNest dashboard or navigation, while the content remains in the normal page DOM for accessibility and search indexing.

Approved CSS variables such as --background and --primary are preserved too. This fixes faded cards, transparent buttons, and missing gradients caused by removed design tokens.

Safe by design

We did not add a switch that disables sanitization. Beautified pages are public and generated by an LLM, so removing that boundary would create an unnecessary security risk.

Instead, Beautify has a dedicated CSS policy that allows the visual capabilities needed for a modern landing page while keeping stricter rules for ordinary wiki and blog content.

Running the full Make it Nice flow now regenerates the design brief, so existing projects can benefit from the new language and CSS behavior.

What This Means for You

More deployments can recover without intervention. When owner input is required, the dashboard explains exactly what is missing. Project status reflects the real application and host signals, and public pages can become genuinely responsive without losing their original language.

If a previously broken project uses a private repository, was stuck during a long build, or has an older beautified page, deploy or run Make it Nice again to use the updated paths.