From Paste to Live: Faster Launches and Smarter Deployment Recovery

This release improves the first important promise of VibeNest: paste a repository, understand what is inside it, and get to a live application with less manual repair.

The work spans the landing page, signup handoff, framework detection, database provisioning, and deployment recovery. Several fixes came from real projects that were blocked by edge cases in the deployment pipeline.

Paste a Repository Before Creating an Account

The landing page now has a more explicit deployment flow. The hero animation shows the path from repository input to build steps to a live URL, and the surrounding trust chips are easier to read.

More importantly, the repository field is no longer just a visual promise. An anonymous visitor can paste a GitHub URL and get a lightweight preview before signing in. VibeNest checks the repository server-side, identifies the likely build path, detects whether it looks like a monorepo, and prepares the future subdomain without spending LLM credits.

After signup, solo repositories can continue directly into /dashboard/launch, where the project is created and the normal deployment chain starts automatically. Monorepos still go through the wizard because they need an explicit service choice.

The handoff also survives email registration. A short-lived launch cookie keeps the repository context when the email confirmation flow drops the original return URL, so both Google signup and email signup can resume the same launch.

More Repositories Deploy Correctly on the First Try

Several framework and runtime paths are now detected earlier and more accurately.

Streamlit projects now receive a real start command instead of relying on a generic Python default. VibeNest detects Streamlit, picks the entry file, sets port 8501, and pushes the required NIXPACKS_START_CMD on redeploys too. The fix matters because a Streamlit app can build successfully and still crash if the server process never starts.

The repository reader also keeps more of requirements.txt and pyproject.toml, so frameworks hidden below the old 100-line cutoff are no longer missed. Streamlit is checked before more generic FastAPI signals, which avoids misclassifying projects that include FastAPI only as a transitive dependency.

For backend projects, database detection now looks beyond package names. Prisma, TypeORM, Drizzle, Sequelize, SQLAlchemy, Laravel, and similar projects can be identified through connection strings, schema.prisma, and environment examples. If a repository declares a Postgres or MySQL requirement, VibeNest can attach the right managed database before the first deployment attempt.

Required Secrets Are Filled More Carefully

Some applications validate configuration through a schema rather than by throwing an obvious runtime error. Those projects could fail before VibeNest had a useful missing-variable signal.

VibeNest now reads declared required keys from committed environment examples and can generate internal application secrets such as JWT signing values before the first build. It does not invent external credentials such as SMTP, S3, payment provider, OAuth, or webhook secrets.

Redeploys are more conservative too. Existing user-provided values are preserved, even if they look weak or placeholder-like. That prevents a deploy from rotating a session or JWT secret and invalidating a working application.

Recovery Works Without a Fragile Browser Click

Some blocked projects were not failing because the deployment engine was wrong. The dashboard click that should have started a redeploy was not reaching the server after the Blazor circuit disconnected.

There is now a server-side redeploy trigger for authorized operational flows. It gives support and automation a way to start a deployment without depending on a live dashboard websocket.

AI Doctor also handles a newer class of Vite and rolldown build failures. Some cross-platform lockfiles omit the Linux native optional dependency needed by rolldown. VibeNest now detects the case, pins the matching binary package from the deployment source, and splices the install into the build command while keeping the lockfile intact.

That is intentionally lighter than deleting lockfiles and asking npm to resolve the entire dependency tree again. The goal is a targeted repair, not a slow and risky rebuild of the world.

Deployment State Heals Itself More Often

Several stale deployment settings are now corrected during redeploy:

• lost or incorrect deployment domains are reasserted on solo redeploys;
• stale Dockerfile build-pack settings can move back to Nixpacks when the deployment source does not contain a Dockerfile;
• managed fork URLs are applied even when no fresh patch was needed in the fork;
• recipe-provided environment variables are re-derived on redeploy, not only during the first deployment.

The free hardware slot flow is also smoother. If a user has an available free slot and starts a deployment, VibeNest can claim it automatically instead of leaving the project silently idle.

What This Means for Builders

More projects should reach a live URL without the owner learning deployment internals first. Streamlit apps, Prisma/Postgres backends, Vite apps with rolldown native bindings, and repositories that need generated internal secrets all have a cleaner path.

When VibeNest still needs owner input, the dashboard should explain the missing step instead of failing as a generic crash loop.