Go live

This is the launch sequence for the SaaS application built from the foundation. It is not a claim that the foundation's own pre-release source distribution is ready to sell. Start only from a clean, tagged application commit with a named release owner and a rollback decision.

Use Deployment to select and operate infrastructure. This page orders the work that crosses infrastructure, the product, and the enabled providers.

Launch outcome

A launch is ready when a real user can reach the intended HTTPS origin, create and recover an account, receive transactional email, use the product's critical path, pay when billing is enabled, and receive a safe failure when an optional capability is absent. The release owner can observe the service, restore data, and roll back the application without guessing.

The foundation ships an authenticated product application, not a marketing site, legal copy, or product domain. Read Product scope before treating a foundation capability as a customer promise.

1. Make the product identifiable

Complete these decisions before creating public accounts:

• Generate the application with its final working name and scope, then complete the maintained branding and design-token path.
• Replace the starter dashboard with the product's real first-use outcome. Do not launch a neutral screen as though it were a customer feature.
• Publish product-owned terms, privacy, retention, deletion, support, and incident-contact pages, then set VITE_TERMS_URL and VITE_PRIVACY_URL to their public HTTPS URLs.
• Decide the support channel, on-call or incident owner, data-retention policy, and the first customer-facing recovery path.

The source product's commercial policies are not the legal or support documents for the SaaS you build from it.

2. Prove the release candidate

Run the deterministic repository verification from the exact release commit:

vp install --frozen-lockfile
vp check
vp run -r typecheck
vp run -r test
pnpm test:e2e
vp run -r build
pnpm audit --audit-level high
git diff --check

Run database-enabled tests against a disposable database when the release changes persistence, authentication, billing, uploads, or migrations. A passing zero-key test path does not prove a configured provider.

Use Testing for runner boundaries and End-to-end testing for the browser harness. Build a custom-scope/custom-brand reference application if the change affects the foundation or its scaffolder.

3. Establish the production boundary

Choose one supported backend, one frontend target, one storage provider when uploads are enabled, and one billing provider when paid access is enabled. Give production and staging separate database, provider, and secret boundaries.

Before admitting public traffic:

1. Set exact stable HTTPS FRONTEND_URL, SERVER_URL, browser VITE_API_URL, and allowed CORS origins. Production previews must not use the production API.
2. Set the matching TRUSTED_PROXY_PROFILE; do not add a generic forwarded-header trust setting.
3. Run the migration primitive once, then confirm /ready returns 200. /health alone is not a database readiness check.
4. Restore a fresh database from a retained backup in a disposable environment. Record the recovery time and accepted data-loss window before launch.
5. Record the exact image digest, deployment identifier, database backup location, and prior rollback target.

See Configuration for variable ownership and Deployment for supported topology, DNS, rollout, and rollback behavior.

4. Verify identity and communications

Use the exact production origins and a deliverable external mailbox. Verify:

• signup, verification, password reset, magic link, logout, session revocation, and the product's protected critical path;
• Google sign-in and callback only when Google is enabled;
• the Resend sending domain, EMAIL_FROM, and every enabled transactional template;
• a rejected cross-origin request, expired/replayed token, and a private-resource request from a different user;
• that production logs, browser errors, and support evidence contain no secrets, auth links, or customer data.

Read Authentication, Transactional email, and Security before changing cookie, provider, or logging behavior to make a smoke test pass.

5. Verify each enabled provider

An optional capability is either fully configured and proven or visibly unavailable. Do not launch with a partially configured selected provider.

Use the provider-specific verification in Billing and Object storage. For billing, prove the live flow again after the test/sandbox run; a checkout return page never grants access by itself.

6. Release, observe, and retain evidence

Deploy the immutable application artifact. After traffic is admitted, verify the exact public origins, an authenticated browser session, the buyer-critical product outcome, PWA update/offline behavior, and every enabled provider flow.

For the first launch window, monitor readiness, structured errors, provider event failures, reconciliation output, database capacity, and deployment alerts. Preserve only redacted evidence:

• release tag/commit, artifact digest, and deployment identifier;
• verification command output and browser smoke result;
• migration result, backup/restore result, and rollback target;
• provider event IDs and reconciliation report without payloads or credentials;
• the owner and escalation path for security or service incidents.

Follow Troubleshooting from the first observable failure. A failed migration, ownership check, provider signature, or recovery test stops the launch; do not hide it behind a client-side success state.

Stop conditions

Do not release when any of these are unresolved:

• a customer-facing policy, support contact, or product outcome is still placeholder content;
• migrations, backup restore, health/readiness, or rollback are unproven;
• browser origins, cookie behavior, or trusted proxy profile differ from the deployed path;
• an enabled provider lacks its complete credentials, live configuration, or failure-path proof;
• a test, audit, or browser smoke was skipped without an explicit owner and release decision;
• a release depends on an unrecorded manual production database change or secret value.

Record the deferred item and its owner before choosing to release without a non-critical proof. Do not relabel a deferred check as passed.