Skip to main content
LaneSync turns your GitHub workflow into a provable release pipeline. These concepts apply whether you use the hosted SaaS or a self-hosted deployment.

​
The release pipeline

Every milestone moves sequentially through six stages. The backend state machine computes the current stage from live GitHub data — issues, PRs, workflow runs, evidence, and deployments.
Stages cannot be skipped. Deploy readiness is only computed when all prior gates pass.
See Release pipeline for entry and exit conditions per stage.

​
Three-layer enforcement

LaneSync does not rely on policy documents alone. Enforcement happens at three layers:

​
Configuration: one file per repo

Each repository owns its SDLC policy in sdlc.yaml at the repo root. LaneSync reads this file live from GitHub on stage-detail requests (60-second cache). The database required_checks column is a cache that may lag until a push webhook fires.
Never hardcode check names in application code. Check names in required_checks must match your GitHub Actions job names exactly — and they must come from sdlc.yaml.

​
Data flow

​
Multi-tenant isolation

Each GitHub organization is a tenant. PostgreSQL row-level security (RLS) ensures data isolation. Users sign in with GitHub OAuth and pick a workspace when they belong to multiple orgs.

​
Where to go next

Release pipeline

Gate conditions for every stage.

Enforcement

Rulesets, state machine, and CI action.

sdlc.yaml

How config propagates through the system.