Vibe Coding App

Why deploy vibe-coding-app on Render?

vibe-coding-app is a reference implementation of a prompt-to-production app builder. Type an idea such as "Build a website for a neighborhood bakery," and a few minutes later you have a public URL. Its agents design the app, write the code, and verify it in an isolated Sandbox. The workflow then publishes the app to GitHub and waits for a real Render deployment to pass public smoke tests.

Most prompt-to-app demos stop at generated code or a preview. Shipping that code as a real multi-service deployment raises harder questions: where model-written code runs and what it can reach, how to keep the model away from your GitHub token and cloud API keys, how an agent can create infrastructure without being able to create anything at all, and how you know the deployed app works rather than just that it built. This repository answers each of those in code.

Simple prompts produce a static site. When the idea needs saved, user-written data, the factory produces a React frontend, a Node API, and a dedicated Render Postgres database, with migrations, seed data, environment wiring, and health checks. Each generated app gets its own Render project and can be deleted through the same factory.

Architecture

The gateway authenticates callers, validates requests, claims runs in Postgres, starts Workflow tasks, and serves a small browser UI. It holds the Render API key it needs to start tasks, but no model key or GitHub credential.

The Workflows service runs the agents and every deterministic stage: design, build, verification, publishing, deploy checks, and deletion. The builder agent writes and runs code only in a disposable build Sandbox that has no credentials and no clone of the apps repository, and that can reach only the npm registry and two package mirrors over HTTPS. Publishing happens in a fresh Sandbox that no agent has touched and that can reach only GitHub.

Generated code is committed under apps/<user>/<app>/ in a separate GitHub repository. Render watches a root render.yaml in that repository with Blueprint Auto Sync, so every infrastructure change is declarative and reviewable.

What you can build

After setup, open the factory UI and submit an app idea. A stage table shows where each step runs, how long it takes, and links to the matching Render Dashboard pages. You can also submit from the included demo CLI or the authenticated HTTP API.

Two agents do the judgment work:

• The architect inspects your Render workspace through a read-only set of Render MCP tools, chooses the smallest set of primitives the idea needs, and writes a structured product brief with real content, pages, and photo subjects.
• The builder creates the app from scratch in the Sandbox, choosing its own stack and layout, using six scoped tools for reading, writing, searching, patching, and running commands.

Trusted workflow code handles everything else. It downloads photographs from Wikimedia Commons, with credits, for the builder to use. It builds every service from a clean tree, boots APIs with and without a database, and runs migrations twice to prove they are idempotent. It also requires real data from a database-backed endpoint and sends failures back to the builder for a bounded number of repairs. Only an app that passes verification is published.

The default factory supports three shapes of app:

• a static site for content, brochure, and catalog experiences;
• a static site plus a Node web service for dynamic behavior; and
• a static site, Node web service, and managed Postgres database for persistent data.

After Render deploys the generated Blueprint, the workflow checks the public site, the API's health and data endpoints, and CORS from the site's origin before marking the run deployed. If a deploy fails, the workflow redacts that deploy's logs and gives them to the builder for a bounded repair.

Key features

• Prompt-to-production workflow: Turns a natural-language idea into generated code, a Git commit, Render infrastructure, and a verified public URL.
• Durable, observable stages: Render Workflows runs prompt-to-app as a parent task, and its agents and steps as subtasks, each with its own run and logs in the Dashboard.
• Disposable build environment: Model-authored code runs in a Render Sandbox with no GitHub token, no Render API key, no apps-repository clone, and no unrelated source code. When the app needs a database, the Sandbox runs a real Postgres to build against.
• Egress allow-lists on every Sandbox: The build Sandbox can reach only the hosts listed in factory.config.ts (by default, the npm registry and the two package mirrors its Postgres installs from), and the publish Sandbox can reach only GitHub. The factory refuses any Sandbox whose reported network policy allows more.
• Verification before publication: Trusted code builds each service from a clean tree, checks static output, boots APIs, runs migrations twice, and requires a non-empty data check.
• Blueprint-only infrastructure creation: The builder returns a validated manifest, and trusted code converts it into a constrained render.yaml. Agents never call a create API or write deployment YAML themselves.
• Credential-separated publishing: A fresh publish Sandbox receives the validated files and a short-lived GitHub credential only after agent work is done. It stages and pushes only the app's own directory and the root Blueprint.
• Run state and concurrency control: Factory Postgres tracks ownership, progress, stage timing, app identity, URLs, idempotency keys, and a global cap on concurrent runs.
• Read-only workspace context: The architect sees the factory's Render workspace through an allowlisted, read-only set of Render MCP tools. Code enforces the allowlist and pins every call to that workspace.
• Lifecycle management: The same UI and API delete a generated app's Render resources and remove its files from the apps repository through restartable steps.

Use cases

• An AI platform engineer studies how to go from generated code to a verified, multi-service deployment.
• An internal tools team builds a controlled app builder for prototypes, departmental utilities, or small-business sites.
• A developer experiments with agent roles, prompts, models, tools, starter templates, and verification gates without building the orchestration layer from scratch.
• A platform team uses the project as a reference for separating untrusted model execution from credentials and infrastructure authority.

What's included

The factory's Blueprint creates the services, database, and environment groups in a vibe-factory project. Because the gateway links only the shared group, the model key and GitHub credential never reach it. Generated apps are separate: each gets its own Render project containing a static site and, when needed, a web service and Postgres database. App names include part of the run ID, so similar prompts never overwrite each other.

The repository also includes a browser UI, an authenticated HTTP API, a demo CLI, a read-only doctor diagnostic, a full-stack starter template, a behavior-focused test suite, and guides for setup, extension, architecture, and reusable design lessons.

Prerequisites

• A Render workspace with Workflows and Sandboxes enabled.
• A Render API key and the workspace ID.
• An Anthropic API key.
• An empty GitHub repository for generated apps, separate from the factory repository, with the Render GitHub app installed on it so Render can read it for Blueprint sync.
• A separate GitHub App or fine-grained personal access token with Contents: write on only the apps repository. The factory uses it to push generated apps.
• A lowercase UI username and a UI password of at least 16 characters.
• Paid Render resources. The factory runs a web service, a Workflows service, and Postgres. Generated APIs and databases also use paid plans and bill until you delete them; generated static sites are free.
• Node.js 22 or later and the Render CLI for setup and diagnostics, plus Docker if you run the factory locally.

Next steps

1. Deploy the factory. Use the Deploy to Render button or create a Blueprint from the repository's render.yaml, then enter the Render, Anthropic, GitHub, apps-repository, and UI values it prompts for. Each secret is entered once, into its environment group, and the Blueprint generates the API key. Both services build from the repository that holds the Blueprint, so a fork runs its own code.

2. Initialize the apps repository. From a local checkout with APPS_REPO and a GitHub credential in .env, run:

   This commits the empty root render.yaml that the apps Blueprint will watch.

3. Connect the apps Blueprint. In the Render Dashboard, create a Blueprint from the apps repository with branch main and path render.yaml, and keep Auto Sync enabled. This is a one-time manual step. Until it's done, runs commit their apps but end as awaiting_blueprint, and connecting it later deploys everything already committed.

4. Check the wiring. Copy the deployed values from the gateway and the two environment groups into a local .env, and run npm run doctor. It checks your credentials, model availability, GitHub access, the apps Blueprint and Auto Sync, the Render MCP allowlist, the database schema, and workflow task registration.

5. Create your first app. Open the gateway URL, sign in, and submit an idea such as "Build a website for a neighborhood bakery." A successful run ends as deployed, with links to the live app and its Render project.

6. Clean up and customize. Delete apps you no longer need from the UI so their paid resources stop billing. Then use the extension guide to change models, prompts, agent tools, supported primitives, the starter template, or the pipeline itself.

Current limits

This project is a reference application, not a multi-tenant app-building platform. One Basic Auth user and one shared API key provide no tenant isolation, per-user quotas, or abuse controls. It supports static sites, Node web services, and Postgres. Success is decided by deterministic verification and live smoke tests; there is no browser testing or model reviewer. The builder has broad shell access inside its credential-free Sandbox. A generated stack that downloads from anywhere other than the npm registry needs that host added to the build Sandbox's allow-list, and DNS lookups still leave the Sandbox.

Every run uses model tokens and a real Sandbox, including local development, and generated services and databases keep running until you delete the app. Failed runs don't resume from a checkpoint; submit the prompt again.

Resources

• vibe-coding-app README
• Quickstart
• Extension guide
• Architecture and trust boundaries
• Design takeaways
• Render Workflows docs
• Render Sandboxes docs
• Render Blueprints docs