What Changed in VibeNest: From GitHub Buttons to Reliable Redeploys

Over the last few days we shipped several different, but closely related, improvements across VibeNest. The first deployment path is shorter, project pages are easier to refresh after edits, Python/Django and Laravel projects recover more reliably, and deployment history no longer disappears just because the current project status has moved on.

The main idea behind this update is simple: VibeNest should feel less like an infrastructure panel and more like the shortest path from "here is my repository" to "here is my live project."

A Shorter Path from GitHub to Deployment

Projects can now be launched through a Deploy to VibeNest button directly from a README.

For open-source templates and demo projects, this is a small detail with a large effect. Repository authors no longer have to explain where users should go or what they should paste. The button opens VibeNest with the repo already attached, then the user goes through the preview/start flow and starts the deployment.

We also added GitHub sign-in. That is a more natural fit for a product where users usually begin with a repository. Previously there was a small mismatch: VibeNest asked for a GitHub URL, but sign-in happened through another provider. Now the flow is more direct: GitHub authorize -> return to VibeNest -> deploy.

Private repository access is handled as a separate step-up. Normal sign-in does not ask for broad repo permissions. If a user wants to deploy a private project, they explicitly connect the access needed for that case.

Promo Codes Can Now Grant More Than Credits

A promo code no longer has to mean "add credits to my balance."

Codes can now grant ready-to-use hardware. A user enters a code on Billing, receives a server in their inventory, and can then attach that server to a project.

Because of that, the promo-code input moved into its own card. Before, it was tucked inside the balance section and looked like something only meant for credits. Now it is clearer that a code can apply to either credits or hardware.

Wiki Pages Can Be Refreshed After Edits

AI pages in VibeNest work as generated HTML versions of wiki content. There was a subtle trap here: if the owner edited the source text, the polished public HTML page could stay stale.

Owners now have an Update HTML version action.

This is not a full redesign. It is a low-cost refresh: take the latest text, reuse the existing design brief, and regenerate the HTML version. Importantly, this is not a background auto-refresh, because silently charging credits in the background would feel wrong. The user clicks the button and knows exactly what is happening.

Light Mode and Live Demos

VibeNest is no longer dark-only.

There are now System, Light, and Dark themes. System follows the operating-system preference, while Light and Dark can be selected explicitly. The theme covers the landing pages, dashboard, account pages, admin, project content, and markdown/prose pages.

This was not just "make the background white." The interface has been moved onto semantic tokens, so components are not held together by random text-white and dark: classes. That lowers the chance that the next new page is readable in only one theme.

The second part is live-demo apps. The first ones are IT-Tools and Excalidraw.

The idea is straightforward: visitors can open a live utility without signing up, try it, and then click "Deploy your own." This is a good format for client-side open-source apps: little server-side state, very little moderation surface, and immediate visible value.

Python and Django Deployments Repair Better

One Django project exposed a chain of problems: runtime.txt pinned an old Python version, dependencies required a newer one, the app started incorrectly inside the container, and migrations were not being applied.

VibeNest now recognizes those cases better.

If a dependency requires a newer Python version, the platform can raise the runtime. If a failed command breaks the virtualenv, VibeNest can repair the install path. Django projects now get a more correct startup sequence: apply migrations, collect static assets, run Gunicorn, and listen on 0.0.0.0 instead of only localhost.

One important detail: AI Doctor is now more careful. If the problem is a Python version mismatch, it should not blindly replace the install command. It should fix the runtime mismatch itself.

Deployment History No Longer Disappears

Previously, there was a frustrating UX failure mode: a user started a deployment, VibeNest really sent it to Coolify, but later the project appeared as Idle with empty logs. From the interface, it looked like nothing had happened.

Every deployment attempt is now stored separately as a DeploymentAttempt.

It keeps the repo, branch, commit, provider deployment id, status, error, and a short log tail. Admin Ops can now show the timeline: the deployment was started, this is where it went, and this is how it ended.

That matters especially when a project is archived during a build, or when the current project status changes later. The current status should not erase the history of a deployment that really happened.

Safe Redeploys for Laravel Compose Projects

Laravel/docker-compose projects now have a more reliable safe-redeploy path.

The problem was not only "start it again." Laravel can be running while still generating incorrect http:// links behind an HTTPS reverse proxy. It can also keep stale configuration through a persistent volume mounted on bootstrap/cache.

Before a safe redeploy, the managed fork is now synchronized with the user's upstream code. Then VibeNest reapplies its platform patches: APP_URL, forwarded headers, HTTPS-aware URL generation, database env defaults, and cleanup for dangerous cache-volume behavior.

In other words, the user gets fresh code without losing the fixes that made the project work in the first place.

The Larger Direction

This is not one big flashy release. It is a set of improvements around one promise: VibeNest should bring more projects to a live state and explain more clearly what is happening along the way.

Fewer manual steps during the first deployment.
Fewer stale public pages.
Fewer cases where something is technically running but not really working.
Less lost deployment history.
More clear actions for users and operators.