Getting startedTutorial

Quick start

Create a workspace, connect your stack, and run a first stored check.

Getting started

Quick start

Ship a real launch baseline in under fifteen minutes. This guide walks from an empty workspace to a stored check run, active watchdogs, and an optional release rule — using the same flows your production stack will depend on.

PreFlight is most valuable when it checks the same credentials, callback URLs, and health endpoints your launch will use. Use staging keys first, then repeat with production credentials before you open signups.

Before you begin

Step-by-step

Create a workspace and project. Sign up, create a workspace, then add a project for the app you are launching. One project equals one deployable surface with its own URL and credentials. Save your public URLs. Add the health endpoint and webhook route your production stack exposes. The readiness scanner only probes the URL saved on the project — never unrelated domains. Connect launch-critical providers. Use Connect Stripe or Connect Supabase when OAuth is available. For the rest, import a local `.env` file in your browser and choose the variables PreFlight recognized; the file itself is never uploaded. Manual fields remain under Advanced. Run one full audit. Open Audit and choose Run full audit. Security, performance, SEO, AI visibility readiness, accessibility, compliance, and quality results arrive under one run. Disconnected providers remain setup items instead of becoming fake failures. Fix blockers with Recovery Guides. Failed probes link to deterministic Recovery Guides with verification steps. Warnings deserve a human review before launch even when the release rule is in relaxed mode. Turn on Health. Add an uptime monitor once and let Health increase observation around a new deployment. Add a user-flow check for signup or checkout, and Revenue protection when Stripe must match a Supabase side effect. Arm a release rule. When CI or Vercel should block unhealthy releases, configure [Release Rules](/docs/guides/deploy-gates) and wire `GET /api/v1/projects/:id/deploy-gate` into your pipeline.

What PreFlight stores

| Category | Examples | Never stored | | --- | --- | --- | | Project metadata | Name, health URL, webhook URL, environment labels | Customer PII from your app | | Credentials | Encrypted provider bundles per integration | Raw keys after save (only hashes + prefixes for API keys) | | Evidence | Check runs, Uptime Monitoring samples, incidents, activity log | Full webhook payloads with secrets | | Automation | Deploy-gate policies, Uptime Monitoring cadence, alert routing | Fabricated or demo telemetry | Exports, Trust Center pages, and dashboard charts reflect stored rows only. If a module has no data yet, the UI stays empty instead of showing placeholder metrics.

Recommended first-run stack

For most indie SaaS launches, connect these providers before your first check:

| Priority | Provider | Why | | --- | --- | --- | | 1 | Stripe | Payments, webhooks, and checkout side effects fail silently at launch. | | 2 | Supabase or Clerk | Auth callbacks and database guardrails block signups. | | 3 | Resend or Postmark | Transactional email proves alert routing works. | | 4 | Vercel | Deployment and domain drift surface after the first promote. | | 5 | Sentry | Error reporting confirms observability is wired. |

After the baseline

Run a [Stripe shadow checkout](/docs/guides/verify-stripe-checkout-without-a-real-credit-card) to validate the full money path. Publish a [Trust Center](/docs/guides/trust-center) report when customers or investors ask for evidence. Create an API key and connect the [MCP server](/docs/api/mcp-server) so agents can re-run checks from your IDE.