Are the latency and safety numbers in the README something I can verify?

No. The comparison table asserts roughly 240 to 300 ms for its own calls, about 10 ms for regex and 3,500 to 6,000 ms for GPT-4 or Claude, and 0% hallucination risk, but the repository ships no benchmark harness, dataset or method behind them. Treat the gate as an additional check, not as measured evidence.

Will a regex linter just do this faster?

The README's argument is that a nested statement, transaction block or multi-statement migration can slip past naive pattern matchers, which is why a model classifies the statement instead. Its own table also puts regex at about 10 ms and calls it bypassable, so the tradeoff is speed against coverage, and neither side of that table is independently reproducible.

How do I wire this into my own migrations rather than the sample ones?

npm run guard:check reads pending migrations under prisma/migrations, or pass a single migration directory path to check just that one. In CI the gate job fails the step on any 403 and the deploy job is conditioned on it, which is the part that actually stops a destructive migration from reaching production.

What does it need installed before it will start?

Node 20 or 22, a TypeSafe API key and a Postgres database, then copy .env.example to .env and fill in TYPESAFE_API_KEY, TYPESAFE_MODEL and the two connection strings. You also have to run npm run prisma:generate, otherwise the dev server on port 3005 starts without the client it expects.

What response does the migration guard return?

One request body with sqlCommand and environment; the response carries status, verdict (SAFE or DANGER), blocked, latencyMs, model, confidence and a probability distribution, returning HTTP 403 to halt CI or HTTP 200 to let Prisma migrations proceed.

How is the migration guard wired into CI and deployment?

A GitHub Actions workflow runs a migration-safety-gate job on every pull request and main commit and gates deployment behind it. A deploy script does a pre-flight guard check, prisma migrate deploy, a PM2 cluster reload and a health-check rollback, with a --simulate dry run.

How do I run the guard check locally?

npm run guard:check scans pending migrations, or pass a single named migration directory. You need Node 20 or 22, a TypeSafe key and a Postgres database, and must run npm run prisma:generate before the dev server on port 3005.

CommunityJev Agents & MCP

TypeSafe Migration Guard

Next.js service with a POST /api/migration-guard endpoint that asks Jev a SAFE or DANGER choice about a SQL statement plus target environment, returning HTTP 403 to halt a CI step or HTTP 200 to let Prisma migrations proceed against Postgres.

See highlights

Open github.com

Stars: 2
Language: TypeScript
Published by: Community
Author: opaielsheikh
Last verified: Oct 2026

opaielsheikh/typesafe-migration-guard

User repository on GitHub

View on GitHub

Automated database migration safety reviewer powered by TypeSafe AI (Jev System One model)

Forks: 0
Last pushed: Updated Sep 2026

Repo stats from the GitHub API, cached Oct 2026.

About this project

Typesafe Migration Guard is an automated, deterministic safety gatekeeper that intercepts database migrations in continuous integration (CI/CD) pipelines and production deployment runners. Powered by the TypeSafe AI SDK and its machine-native Jev System One model, it evaluates DDL statements in real-time, blocking destructive operations (such as DROP TABLE, DROP COLUMN, and unindexed truncation) with an HTTP 403 Forbidden status code before any migration touches your live Supabase PostgreSQL database.

Quoted from the project's README. Read the full README.

Tagscommunity jevbest catalog-import awesomejev

Works forJev for Classification Jev for Moderation

Used inJev for Software & DevTools

Languages: TypeScript

Highlights

One request body with sqlCommand and environment; the response carries verdict, blocked, latencyMs, model, confidence and a probability distribution.
A GitHub Actions workflow runs a migration-safety-gate job on every pull request and main commit and gates deployment behind it.
npm run guard:check scans pending migrations or a single named migration directory, so the gate runs locally too.
deploy-ec2.sh does a pre-flight guard check, prisma migrate deploy, a PM2 cluster reload and a health-check rollback, with a --simulate dry run.

Watch out

The latency figures are the README's own, not a measurement you can rerun: its comparison table puts this project's calls at roughly 240 to 300 ms, regex linters near 10 ms and conversational models at 3,500 to 6,000 ms, with no harness or dataset in the repository behind them. Configuration is Supabase-shaped, with DIRECT_URL for migrations and DATABASE_URL through Supavisor, though a local Postgres also works. The clone command in the README still says your-org, so expect to fix the URL. Prerequisites are Node 20 or 22, a TypeSafe key and a Postgres database, and you must run npm run prisma:generate before the dev server. Only two migrations ship as fixtures, one CREATE TABLE and one DROP TABLE CASCADE. Copy reviewed against the repository README on 2026-10-04, not from running it.

Questions about this entry

Short answers drawn from the linked project or page.

More Jev resources like this

jev-test-filter

Diff-aware test selector that sends the git diff to Jev with one question per test, then prints the native filter flags and hands them to vitest, jest, node, bun, Playwright, cargo, or go test.