Drydock
Your AI Production Engineer

Is your app ready to ship?

You built it with Lovable, Bolt or v0, and it works. Drydock reads the code the way a production engineer would before letting it near real users — and tells you, in plain language, what would go wrong and what it costs you to leave it.

Public GitHub repos only. The scan runs in the background — you get a link you can come back to.

Free, and no signup. Paste a public repository URL.

What we go looking for

The things that turn a working demo into an incident: money spent by someone else's hands, a database anyone can read, an app nobody can redeploy. Every item below is a check that runs, not a plan.

  • Credentials sitting in the code

    AWS keys, GitHub tokens, Stripe live keys, Supabase service keys, bot tokens, private keys — committed to the repository, where anyone who gets the code gets them too.

  • Secrets that slipped into git

    A .env committed by mistake, or a .gitignore that never covered the files holding your keys. Both are quiet until they aren't.

  • Authentication that isn't

    not in the free scan

    Routes that change data without checking who asked, hand-rolled token verification, passwords compared without hashing, a server trusting whatever user id the browser sends it, row-level security left switched off.

  • Ways in for a stranger

    not in the free scan

    SQL and command injection, user input reaching somewhere dangerous unchecked, CORS open to any site with credentials, secrets shipped to the browser in NEXT_PUBLIC_ variables, webhooks that accept anything.

  • Nothing catching mistakes

    No tests at all, so nothing tells you the login broke — until a user does.

  • No way to run it anywhere else

    No CI and no Dockerfile, so the app only really exists inside the tool that generated it.

The scan is free. The fix is what you pay for.

Free, no account, no card

The static scan and its full report: credentials committed to the repository, a committed .env, a .gitignore that misses secret files, no tests, no CI, no Dockerfile — each with the file, the line, what a stranger could do with it, and how to fix it yourself.

It gives no score out of 10, on purpose. Two of the four scored categories depend on checks the free scan doesn't run, and a score computed from the rest climbs as fewer things are examined — it would tell you the opposite of the truth.

Paid: the fix, as a pull request

A Fix Pack moves hardcoded credentials into environment variables, removes a committed .env, repairs .gitignore, and opens one pull request against your repository. You read the diff and decide whether to merge it. Bought once, for that one audit.

What a Fix Pack will not touch

Missing tests and missing CI come back as findings with guidance — not as code we wrote for you. Nor would we rewrite a login: doing that to an app we saw for the first time ten seconds ago is how an audit tool locks you out of your own product. And when there is nothing a Fix Pack can safely change, checkout refuses the sale instead of taking your money and reporting that it found nothing to do.

The deeper review

included with a Fix Pack

Whether your routes verify who is calling them, whether passwords are hashed, whether row-level security is on, whether user input reaches somewhere dangerous. It is also what the score out of 10 is computed from, which is why a free scan carries no score. You can't buy it on its own — buy a Fix Pack and the pull request arrives with a link to the full review of the same code.

How paying works →

See what you get

A sample report, rendered exactly as a real one is. This one is the full review, so it carries a score; the free scan shows the same per-finding detail without it.

Example reportIllustrative data — not a real audit

Production Readiness

Some work before launch

stack: nextjs

files scanned: 128

2 critical1 high1 medium2 low
Security
1.8
Auth
6.2
Testing
6.4
Deploy
8.5

  • A live Stripe payment key is written directly in your code.

    Fix before launch

    This key moves real money. Anyone who finds it can issue refunds, read customer payment data, or create charges.

    Roll the key in the Stripe dashboard immediately and keep the new one in environment variables.

    Hardcoded Stripe live secret key · app/api/checkout/route.ts:12 · sk_live_51Nc…9aQ2

  • Your .env file — the file that holds ALL your secrets — is inside the repository.

    Fix before launch

    The .env file usually contains database passwords and API keys in one place. Committing it hands your entire keychain to anyone who ever sees the code.

    Remove it from the repository, add .env to .gitignore, and rotate every secret that was inside.

    .env committed to the repository · .env:1

  • Your Supabase anon (public) key appears in the code.

    Important

    This particular key is meant to be public — it ships in every app's front-end by design, so this is informational, not a breach. The keys that must stay secret are the service_role key and database passwords, which are NOT flagged here.

    No urgent action needed for the anon key itself. Do confirm your Row Level Security is on, since the anon key relies on it.

    Supabase anon key present in client code · lib/supabaseClient.ts:4 · eyJhbGciOiJI…

  • The project has no automated tests.

    Worth fixing

    Every change is a blind edit: things that worked yesterday can silently break today, and you'll learn it from your users.

    Start with a few tests for the money paths — signup, login, checkout.

    No automated tests found

  • The app isn't packaged to run on a server (no Dockerfile).

    Good to know

    It runs on the builder's platform, but moving to your own hosting — often needed for cost or control — will be a wall.

    Add a Dockerfile; our Deploy Pack generates a working one automatically.Enterprise

    No Dockerfile

  • No automated checks run when the code changes (no CI).

    Good to know

    Broken changes reach your live app with nothing in the way.

    Add a simple GitHub Actions workflow that runs the tests on every change.

    No CI workflow