Vibe deployment: simple sites need a simpler way to deploy

Vibe deployment is the missing publishing layer after vibe coding. The agent takes the site it already built to a stable public address, then stays available for the next change.

The failure today is not that deployment is technically hard. The failure is that a simple website is pushed down the operating path of a full application.

That distinction matters. A five-page landing site and a product with user accounts, private data, and background jobs are different objects. They should not have the same path to production.

Vibe coding made the first object easy to create. Vibe deployment should make it equally direct to deploy and update.

The industry keeps answering the app question

Search for vibe deployment and most answers begin with a prototype, then jump straight to application infrastructure. The step they skip is the one people are stuck on: a published artifact is a preview with a link, not a deployment.

A DEV Community article frames the problem through CI/CD pipelines, infrastructure configuration, environment variables, observability and auto-scaling. SD Times describes the prototype-to-production gap through runtime choices, Kubernetes, APIs, security and compliance.

Even advice that starts with websites inherits the same model. Twilio's guide opens with project types, then sends website owners toward AWS, Azure or framework-specific hosting. AddJam distinguishes a static site from a full-stack app, but its simplest route still begins by pushing code to GitHub.

None of it is bad advice. An application really may need authentication, databases, secrets, build logs, monitoring, backups and a controlled deployment process. Some platforms offer that bundle free, EdgeOne Pages among them, and whether you want the whole platform for a static page is the question.

The mistake is making that the default before asking what was built. That default has a cost people hit constantly: what they actually ask for, and what they get told instead. It falls hardest on the people the vibe coding statistics describe, who are mostly not developers.

So classify the output first. A vibe-coded static site can be delivered as finished browser files. A web app needs the runtime, secrets and operations its behaviour requires. The same tools create both, and "vibe coded" describes the build process, not what must keep running afterwards.

First decide whether you built a site or an application

The name of the coding tool does not answer this, and neither does the framework. A React project may produce static files; a Next.js project may require a server. What matters is what must keep running after the files are built. The same question decides whether a builder subscription earns its place, which is what the alternatives pages for v0, Bolt.new and Figma Make work through tool by tool.

Treat the project as a simple site when it can be delivered as pages, styles, images, fonts and client-side JavaScript, with no project-owned server process or private secret:

• a landing page;
• a portfolio or event site;
• product documentation;
• a public menu or small catalogue;
• a browser-only calculator or interactive page.

Use the application production path when the project owns any of these:

• user authentication or access rules;
• private user or business data;
• a database;
• server-side code or private API keys;
• scheduled tasks, queues or background jobs.

The practical question to ask the agent:

After the build finishes, can this project run entirely from static browser files, without its own server process or a private secret in those files?

Yes means deploy it as a site. No means it needs application operations.

There are grey areas, and the rule still holds. A static site can submit a form to a separately managed service or use a hosted checkout without the owner operating a backend. The boundary is not whether the page does something useful, it is whether this project owns server-side code and private state.

Once you know it is a simple site, the next question is whether it needs a full website platform at all. The WordPress vs Wix comparison shows when either platform earns its complexity.

A simple site needs a publishing process

A static site still needs more than a preview: other people have to open it, and the owner has to be able to change it safely.

A good publishing service deploys the finished files without turning that into infrastructure work. It should:

• check that the finished package contains a start page and its assets;
• serve it from a stable HTTPS address;
• keep routes, links and relative paths intact;
• leave the current site untouched when a new publish fails;
• record successful versions and make a bad update reversible;
• make the second publish as direct as the first.

That is real infrastructure the owner should not have to operate. Everything between "finished" and "public" has a name now, the deployment gap, and this list is what closing its first wall looks like.

Source control, runtime, environment and pipeline do not need to be mandatory stages in between. Git stays useful for source history, collaboration and code review; it is not a law of nature that every public site begins with a GitHub handoff.

Simple publishing is not a shortcut for an application. It is the correct workflow for a simpler object.

Vibe deployment should keep the agent in the loop

During vibe coding the conversation stays close to the result:

Make the headline shorter. Move the form higher. Use the blue from the logo.

The usual deployment handoff changes the subject:

Choose a runtime. Set the output directory. Add environment variables. Configure the pipeline.

The owner leaves the conversation and stops directing the site, translating instead between an AI coding tool and a hosting dashboard. A shorter operations tutorial makes that interruption easier. It does not remove it.

A better loop keeps the context where it already is:

1. The owner connects the agent to the publishing service and chooses a project. The same connection reads what an agent reads before it picks a place to publish to find its own way in.
2. The agent prepares the static output it already understands.
3. The service validates the files before changing the public site.
4. A successful publish produces a stable address and a recorded version.
5. Later edits travel through the same connection.
6. If an update is wrong, the owner or agent rolls back to an earlier version.

Step five carries more weight than its line suggests: what changing a live site actually looks like is worth understanding before you depend on it.

The agent does not need to become an operations team. It needs a narrow, reliable way to finish the job it started, and that connection has an open standard behind it, described in the protocol that keeps the agent in the loop.

If Claude Code holds the finished files, the step-by-step Claude Code deployment guide turns this loop into exact build, publish and rollback instructions. The OpenAI Codex guide and the Cursor guide do the same in those tools.

What Birta does — and where it stops

Birta is built around that narrow loop. A connected agent or chat publishes a finished static site to a project. Birta expects built browser files, checks the package before it goes live, and keeps the existing version active when validation fails. A successful publish creates a new version at the project's public address, and previous versions can be previewed and restored.

The connection has access only after the owner authorizes it. The owner creates and manages projects; the agent handles publishing from the tool where the site was made.

Birta does not run server processes, databases, private application logic or background workers. A project with its own access system, private records, server code or scheduled work belongs on a platform designed for it, with a real production review. Not an unfinished cloud platform, a product boundary.

Before you share the URL

Easy publishing removes unrelated setup. It does not make the site's content, design or client-side code correct. Before sharing it:

1. Open the public site in a private window, which catches files or sessions that existed only on your machine.
2. Check every page on a phone, not only the desktop preview.
3. Click the links and confirm images, fonts and other assets load.
4. Make sure no private key or secret sits in browser files, because visitors can read anything their browser receives.
5. Know how to restore the previous version before publishing the next change.

For a repeatable version of that pass, the website audit template turns the checks into a copyable record.

If the check reveals private data, server-side behaviour or access control, reclassify the project. The site-or-app decision outranks the convenience of the current publishing path.

The missing layer should match the thing being published

Vibe coding is not complete when the result works only on localhost or in a preview. Someone else has to be able to open it, and the owner has to update it without starting a second career in hosting.

The answer is not making every agent fill in every deployment form. It is starting with the object: a simple site gets a simple, reversible publishing path, and an application gets the operational discipline its data and behaviour require.

That is the useful meaning of vibe deployment. Keep the agent in the conversation, keep the public site safe between versions, and do not force an application stack onto a folder of web files. To publish from the tool you already use, start with the Birta connection guides.

Frequently asked questions