PLANETSCALE SECURITY CHECKLIST

PlanetScale’s branching model means most security failures happen at the boundary between branches — production credentials reused on a dev branch, dev data restored over production, schema migrations promoted without review. The checklist below is what we look for first when we audit a PlanetScale-backed app.

Treat Critical as launch-blocking. High is week-one. Medium is the cleanup once the database is in production.

How to use this checklist

Walk it once in the PlanetScale dashboard for your production database, ticking items as you go. Audit each branch separately — the safety properties of main don’t extend automatically to staging or to feature branches. After the whole list passes, scan the app that connects to the database to verify no client-side leak undoes the database-side hardening.

Critical (fix before launch)

1. Restrict database access to specific service accounts

Why it matters. PlanetScale connection passwords are tied to roles (admin, read-write, read-only). Admin passwords can change schema. We routinely see apps deployed with admin credentials because that’s what was generated first — meaning a compromised app instance can drop tables.

How to check. In Settings → Passwords, audit each password’s role. Production app services should be read-write or narrower; only ops tooling should be admin.

How to fix. Generate a new password with the minimum role the service needs, switch the service to it, then revoke the old password.

2. Use branch-scoped connection strings

Why it matters. A password generated against the main branch grants access to main only. A password generated at the org level (or against multiple branches) gives broader access — and if leaked, exposes more.

How to check. Confirm each password lists exactly one branch in its scope. Audit any “all branches” passwords; revoke them.

How to fix. Generate per-branch passwords for each service. The service’s deployment env points only at its branch.

3. Enable IP allowlisting on production

Why it matters. Without IP restrictions, anyone with the connection string can connect from anywhere. Combined with credential exposure (which happens), that means a leaked password is immediately exploitable.

How to check. In Settings → Network, confirm IP allowlist is configured for the production branch with your app server IPs.

How to fix. Add the IP ranges of your app hosting (Vercel, Fly, AWS, etc.). For platforms with rotating IPs, set up a NAT or proxy with a stable IP that PlanetScale can allow.

4. Strip schema migration scripts of test data with PII

Why it matters. Migration scripts that include sample data sometimes inherit production-shaped data — real names, real emails — copied from a local dev environment seeded against a production dump. Once committed, that data lives in git history forever.

How to check. Diff every migration in your migrations/ directory against a fresh template. Search for realistic-looking data (@gmail.com, @outlook.com, recognizable names).

How to fix. Replace with synthetic data (user-{i}@example.com). For migrations already shipped, document the breach and rotate any exposed credentials.

5. Require deploy request review before merging schema changes

Why it matters. PlanetScale’s deploy requests are the schema-change equivalent of PRs. Auto-merging without review means a bad migration (drop unique constraint, change column type) can hit production unreviewed. We have audited cases where this caused silent data corruption that took weeks to detect.

How to check. In Settings → Deploy Requests, confirm review is required, and audit recent deploy requests for who approved them. Multiple approvals are better than one.

How to fix. Enable “Require approvals”. Set CODEOWNERS-equivalent rules so schema-sensitive tables require database team approval.

6. Confirm no application code uses admin-role credentials

Why it matters. A common pattern: developer generates an admin password to test the connection, copies it into the app’s env, ships. The app now has DROP TABLE privileges in case anything ever exploits it.

How to check. Diff your deployment env’s DATABASE_URL against the role list in the dashboard. Confirm the role is read-write (or narrower), not admin.

How to fix. Generate a read-write password, switch the env, revoke the admin one.

High (fix in the first week)

7. Rotate connection strings on a schedule

Long-lived passwords drift. Rotate quarterly, on team member changes, and after any near-leak. PlanetScale supports overlapping passwords for zero-downtime rotation.

8. Enable audit logs on the production branch

In Settings → Audit Log (paid plan), confirm logging is on. Ship logs to your SIEM. You want the record of every schema change, password rotation, and access attempt long after the default retention.

9. Use safe-migration mode for schema changes

PlanetScale’s online schema change is safer than direct DDL but still has edge cases. Use the safest mode available for the change type, and run schema changes against staging before production.

10. Configure least-privilege database users per service

Each service connecting to the database should have a password scoped to the operations it actually performs. Read-only services use read-only passwords, even if generating a read-write one is “easier.”

11. Verify branch promotion does not skip review

Promoting a feature branch to a deploy request and then auto-merging skips the human review of the actual schema diff. Review deploy requests in the UI, not just in the PR description.

12. Audit who can create and delete branches

Branch creation is cheap; branch deletion can be destructive (especially for a branch with uncommitted work). Restrict who has the role.

Medium (fix when you can)

13. Disable web console for the production branch

The PlanetScale console is convenient and a foot-gun. Disable it for production; require CLI access through audit-logged tooling.

14. Pin Vitess/MySQL version expectations

Application code can rely on subtle MySQL behavior. Document the version you target and don’t accept silent upgrades that change behavior.

15. Document branch promotion rules

A short doc covering: who can open deploy requests, who reviews schema changes, how data migrations are coordinated. Saves a lot of reactive Slack threads.

16. Set query timeout defaults

Long-running queries are usually a bug or an attack. Set a query timeout (MAX_EXECUTION_TIME hint or per-app config) so a runaway query doesn’t take down the database.

17. Restrict who can rotate passwords

Password rotation requires admin role. Audit who has it; restrict to the smallest possible group.

18. Set up alerting on connection-count anomalies

A sudden spike in connections (or in failed-auth attempts) is a sign someone’s testing your database. Alert on outliers.

After every schema change

• Diff the deploy request schema against main carefully — column type changes, dropped indexes, removed constraints all matter.
• Run the deploy against staging first.
• Confirm the app’s queries still work (especially queries the schema change wasn’t trying to touch).
• Re-confirm IP allowlist still includes the app’s IPs.

Common attack patterns we see in PlanetScale apps

The admin-role app password. Service deployed with the first password ever generated, which was admin role for testing. App gets exploited via SQL injection; attacker drops tables.

The org-level password. Password generated at org scope “for convenience” is leaked from a public Vercel preview. Every branch is now exposed.

The unreviewed migration. Deploy request auto-merged because the team uses GitHub’s auto-merge for “small” changes. Migration removed a unique constraint; production silently accepts duplicates for two weeks.

The PII in a fixture. Migration script seeded users with realistic-looking data copied from a local dev that had been seeded against a production dump. Real customer emails now in git forever.

Related Resources

How to Secure PlanetScale

Step-by-step guide for hardening a PlanetScale database — branch hygiene, password roles, deploy request review, and the IP allowlisting above in long form.

Is PlanetScale Safe?

In-depth analysis of PlanetScale’s defaults — what’s locked down, what isn’t, and what we find when we audit a production database.

Automate Your Checklist

A checklist tells you what to look for. A scanner tells you what’s actually broken in the deployed app that connects to your database. VibeEval scans the app, attempts SQL injection and credential-leak vectors, and reports what got through.