Deploy Preflight

Pre-deploy review for solo builders. Offline. No secrets leave your browser.

v0.1.0 · Ruleset v1.0

Deploy Preflight checks your project files for common mistakes before you go live. It catches problems like leaked API keys, missing security headers, and broken configurations — the kind of things that cause real damage after launch.

Upload or paste your project files below. The more files you provide, the more issues the tool can catch. Everything stays on your device — nothing is uploaded to any server.

Why this matters

Many production misses are env/config related — mostly leaked API keys and databases anyone could read. These aren't exotic hacks. They're simple misconfigurations that a quick review catches before they go live.

This tool looks for those exact problems in your config files, so you can fix them before anyone else finds them.

Step 1 — Where are you deploying?
Step 2 — Add your project files
package.json START HERE
Your project's ingredient list — tells us what you're building with
▾
or paste below
📋 Why we need this
Framework detection: We check if you're using Next.js, Nuxt, Remix, etc., and look for problems specific to that framework (like server-only packages accidentally bundled for the browser).
Service integrations: If you've installed Supabase, Firebase, Stripe, or similar packages, we verify you're using them safely — especially important for databases and payment processors.
Build command: We check if your build works properly and your dependencies are locked down (using package-lock.json or yarn.lock).
.env.example
Your secret keys list — this is where most leaks start
▾
or paste below
🔐 Why we need this
You need secret keys to connect to services. When your app talks to a database (Supabase), payment processor (Stripe), or AI API (OpenAI), you prove your identity with a secret key. Without it, the service won't let you in. But if you hardcode those keys directly in your code, they end up in GitHub where anyone can find them.
.env files solve this: Instead of hardcoding secrets, you store them in a .env file that never gets uploaded to GitHub. At runtime, your app reads them from .env and uses them safely. .env.example shows which keys you need, but with placeholder values only — safe to share.
We check: Whether your secrets are properly marked as server-only (so the browser can't see them), whether they're in .gitignore (so they don't leak to GitHub), and whether your deployment platform knows about them.
Platform config
Your hosting settings — controls security headers and build behavior
▾
or paste below
🛡️ Why we need this
Security headers protect your visitors. These are simple rules that tell web browsers to reject certain types of attacks — like clickjacking, XSS injection, and malicious form submissions.
We check for: Content Security Policy (CSP), X-Frame-Options, HSTS, and other headers that nearly every serious site has. Missing headers = unprotected visitors.
Build settings matter too: Node version mismatches, edge runtime incompatibilities, and misconfigured output directories can silently break your deployment or leave files accessible that should be hidden.
.gitignore
Your "do not upload" list — keeps secrets out of GitHub
▾
or paste below
🔒 Why we need this
Public GitHub = public secrets. If your .env file isn't in .gitignore, it's getting pushed to GitHub. Anyone (including bots that scan for exposed API keys) can read it. Once keys are public, they're compromised forever.
We verify: That .env, .env.local, and similar files are properly listed in .gitignore. This is a quick fix that prevents a huge security disaster.
File tree
Your project's folder structure — shows what's present or missing
▾
or paste below
📂 Why we need this
Lockfiles prevent dependency chaos. If you don't have a package-lock.json or yarn.lock, your dependencies can silently change between deployments, breaking your app or introducing security holes.
Missing middleware = exposed routes. If your API routes don't have auth checks in a middleware file, unprotected endpoints could be accidentally exposed to everyone.
We check for: Lockfiles, middleware files, build output directories, and the presence of .env.example. If key files are missing, we flag it.
Short description
Optional — briefly describe your app in plain English
▾
💬 Why we ask for this
Context helps us detect more issues. If we know you're using Next.js with Supabase and Stripe, we can check for problems specific to those combinations — like not protecting Stripe webhook routes, or exposing Supabase's service role key by accident.
Optional, but more context = better checks.
0 of 24 rules · Select a platform to start
Quick review

Here's what we detected from your files. If anything looks wrong, tap it to change it. If you're not sure about something, that's okay — just leave it or select "Not sure."