Launch Projects

A Launch Project is the path from funded repo to running app.

VibeExchange keeps this non-technical. Users should see:

Technical layer	VibeExchange language
Cloudflare Worker	Cloud launch
Domain registration	Web address
Stripe Projects services	Project services
Environment variables	Project vault
Agent deployment task	Managed agent run
Provider budget	Spend limit

Ownership

Launch Projects are customer-owned by default.

That means the app owner owns the Stripe Project, Cloudflare account resources, domain billing, provider subscriptions, and credentials. VibeExchange orchestrates setup and records safe metadata, but it should not become the owner of the customer’s deployed infrastructure unless a future managed-hosting tier explicitly says so.

Stripe Projects fit

Stripe Projects gives agents a single workflow for:

• initializing a project for one app or codebase;
• adding services such as hosting, databases, auth, analytics, email, AI, and observability;
• syncing environment variable names and credentials into the local project;
• managing provider billing and upgrades from a Stripe account.

VibeExchange should treat Stripe Projects as the preferred provisioning path for supported services, while storing only safe metadata:

• provider;
• service;
• resource name or id;
• environment name;
• masked environment variable names;
• dashboard links;
• status and audit events.

It must not store raw .env values, .projects/vault contents, bearer tokens, or provider credentials in D1.

Cloudflare launch

For V1, VibeExchange Launch Projects target Cloudflare Workers.

The launch flow is:

1. Create or link a customer-owned Stripe Project.
2. Add Cloudflare Worker as the first service.
3. Queue a managed agent run to prepare the deploy contract.
4. Deploy the repo-backed app to Cloudflare.
5. Attach a web address.
6. Record the launch state, provider resources, agent spend, and release notes.

Domains

Domain registration must be explicit and auditable:

1. Search for candidate names.
2. Check real-time availability and price.
3. Show registration and renewal cost.
4. Require explicit approval.
5. Register or queue registration.
6. Poll status until terminal state.
7. Bind the domain to the Cloudflare Worker custom domain.

If a provider returns action_required, blocked, or failed, automation stops and VibeExchange surfaces the state to the user or operator.

Agent runs

Agents can run against:

• launch setup;
• Cloudflare deploy prep;
• domain and DNS binding;
• feature cards;
• custom-version sync;
• offer-back integration.

Every managed agent run needs:

• workspace;
• repo target;
• budget cap;
• token envelope;
• user-visible status;
• PR/preview/deploy output when available;
• token/spend report;
• human review state.

V1 status

The first implementation records Launch Projects, services, domains, deployment runs, and agent run queues in D1. External provider actions are safe by default: domain purchases stay disabled unless the operator explicitly enables live purchase mode and the user approves the quoted price.