Catch before they happen in production

Review every pull request against the infrastructure it will actually run on. Find deployment risks while they’re still code changes.

Get Started with GitHub Talk to the team

See Proofline in action

These example reviews connect a code change to production evidence, explain what can fail, and suggest a fix.

Read how a review works

Capacity overruns

your-org / your-repo

Scale API to 12 tasks #42

Openyou want to merge 1 commit into main from scale-api
infra/ecs/api.tf+1 −1
@@ -17,4 +17,4 @@
1717 resource "aws_ecs_service" "api" {
1818 name = "api"
19− desired_count = 4
19+ desired_count = 12
prooflinebotcommented

Database connections run out before all tasks become healthy

Each task opens 20 connections before passing its health check. With 12 tasks, the service needs 240 connections. The production database allows 197.

View evidence
Code
infra/ecs/api.tf:19 sets 12 tasks. The application opens its 20-connection pool before reporting healthy.
Environment
The pinned snapshot of orders-prod records max_connections = 200 and 3 reserved connections.

The extra tasks can fail their health checks and stall the deployment. Reduce the task count or pool size, or add a connection pooler.

2020 }

Permission errors

your-org / your-repo

Restrict access to application config #43

Openyou want to merge 1 commit into main from restrict-config
infra/iam/api.tf+1 −1
@@ -22,4 +22,4 @@
2222 effect = "Allow"
2323 resources = ["arn:aws:s3:::app-config/prod.json"]
24− actions = ["s3:GetObject"]
24+ actions = ["s3:GetObjectVersion"]
prooflinebotcommented

The API loses access to its startup configuration

The startup code calls GetObject without a version ID. The replacement permission allows versioned reads only, so the request is denied and the API cannot start.

View evidence
Code
infra/iam/api.tf:24 replaces s3:GetObject. src/config.ts reads prod.json without a version ID before starting the server.
Environment
The pinned environment snapshot links the API task to this role. No other applicable policy grants s3:GetObject on the configuration object.

Keep s3:GetObject scoped to app-config/prod.json. The API needs that action to load its configuration.

2525 }

Network outages

your-org / your-repo

Move database access to the worker group #44

Openyou want to merge 1 commit into main from database-ingress
infra/network/database.tf+1 −1
@@ -29,4 +29,4 @@
2929 from_port = 5432
3030 to_port = 5432
31− security_groups = [aws_security_group.api.id]
31+ security_groups = [aws_security_group.worker.id]
prooflinebotcommented

New API connections cannot reach the database

This replaces the database’s only ingress rule for the API security group. API tasks still connect to orders-prod:5432, so new connections time out after the rule changes.

View evidence
Code
infra/network/database.tf:31 replaces the allowed source group. The API still opens PostgreSQL connections during startup and when its pool reconnects.
Environment
The pinned snapshot places API tasks in the API security group and the database in the group changed here. No other ingress rule allows that source on TCP 5432.

Retain the API security group in the database’s allowed sources. Add the worker group alongside it if both services need access.

3232 }

Breaking migrations

your-org / your-repo

Rename the order status column #45

Openyou want to merge 1 commit into main from rename-order-status
migrations/018_order_status.sql+1 −0
@@ -0,0 +1 @@
1+ ALTER TABLE orders RENAME COLUMN status TO state;
prooflinebotcommented

The running API still queries the old column

The migration renames orders.status before the API rollout. The currently deployed release still selects status, so order requests fail with a missing-column error while that release is running.

View evidence
Code
migrations/018_order_status.sql:1 renames the column. The deployment configuration runs migrations before replacing API tasks.
Environment
The recorded production deployment identifies the running image and its commit. At that commit, src/orders.ts queries orders.status.

Use an additive migration first. Add and backfill state, deploy code that supports the transition, and remove status after old readers are retired.

Grounded in your infrastructure.

Read-only access to configuration and deployment evidence, through permissions you grant.

Explore all integrations

All integrations are read-only

Before you connect.

What access does Proofline need?

Install the GitHub App for the repositories you choose, then grant read-only access to the infrastructure in the target environment. The required permissions depend on the services you connect. Read about security and data access.

Can it change my infrastructure?

Infrastructure integrations are read-only. Proofline reads configuration and deployment evidence, then publishes supported findings in GitHub. You decide how to address them.

What happens when evidence is unavailable?

Proofline marks the assessment incomplete and identifies the missing, stale, or unreachable evidence. An absence of findings does not establish that a deployment will succeed.

Does it replace tests or staging?

Keep your tests and staging environment. Proofline adds a review of the change against evidence from its target infrastructure, helping you investigate risks that depend on that environment.

Can I start for free?

Yes. Sign in with GitHub to begin setup. Paid subscriptions are not available yet. See the planned pricing for the proposed plan and credit allowance.

Get started for free

Bring one repository and the environment it deploys to.

  1. Connect GitHub

    Sign in and install the GitHub App for the repositories you choose.

  2. Link an environment

    Choose the repository and identify where its changes will run.

  3. Connect infrastructure

    Grant the read-only access needed to review that environment.

  4. Inspect a review

    Read the findings, their evidence, and any gaps before you merge.

Get Started with GitHub Talk to the team