CI/CD and migrations: SQL is checked in the pull request

What it protects

• Destructive DML, with your workspace's action: VERICTO-001 (DELETE without WHERE), 042 (UPDATE without WHERE) and 033 (DELETE without WHERE in a subquery or CTE).
• Schema and DDL, VERICTO-010 to 019 (DROP, TRUNCATE, DROP COLUMN, RENAME, ALTER COLUMN TYPE): in CI and MCP they are capped at FLAG, because a versioned migration contains them for good reason. The pipeline reports them and does not fail; at runtime, the proxy and the API block them.
• Security rules such as VERICTO-080 (COPY … PROGRAM) and 082 (GRANT and REVOKE), with their full action.
• Custom YAML rules (from Builder) for what is specific to your team, for example forbidding physical deletes on a table.

Latency and availability

The check runs in the pipeline, outside the runtime: it adds no latency to your application. With --changed, the CLI checks only the .sql files changed against the merge base, so PRs stay fast.

Each analysed statement counts as one validation: 1K a month on Free, 10K on Builder, unlimited on Team and Enterprise. A batch that does not fit in what is left is rejected whole with 429.

The Runtime API, the Validation API and MCP run in Vericto Cloud, with a 99.5% SLA on Builder and 99.9% on Team and Enterprise (99.95% and 99.99% with a dedicated deployment). Service status is on the status page.

How to implement it

1. Create an API key with the ci_dryrun:execute scope and store it as a repository secret, or use OIDC to avoid a static key.
2. Add the Action: uses: vericto/check-sql@v1 with api-key. It installs a pinned CLI version, verifies its SHA-256 and uploads the findings as SARIF to Code Scanning: CI/CD.
3. On GitLab CI, CircleCI or Jenkins, use the CLI: vericto init generates the GitHub Actions and GitLab CI template.
4. In a repo with existing SQL, record a baseline (vericto baseline) so only new findings fail: baseline.
5. Optional: vericto init --hook installs the pre-commit hook, and the MCP server lets your coding agent check the migration while it writes it.
6. If you change rules from CI, simulate the change against production traffic with a rules:simulate key (Builder, Team and Enterprise).

When not to use this option

• SQL generated at runtime (an ORM, an agent, a console): CI never sees it. That is what the TCP proxy or the Runtime API are for: see web application.
• Migrations that are not .sql files, such as an ORM's code migrations: generate the SQL first, or send the statements to the Validation API.

Plan availability

Prices and every limit on Pricing.

Other architectures

• All reference architectures
• Web application
• Microservices and Kubernetes
• AI agents and text-to-SQL
• Data warehouse and analytics
• Data pipelines
• Serverless and edge
• Multi-tenant SaaS
• Enterprise and regulated