> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tuturuuu.com/llms.txt
> Use this file to discover all available pages before exploring further.

# CI/CD Pipelines

> High-level CI/CD overview, with current operational runbooks linked from one place.

This page is the entry point for CI/CD. The day-to-day operational detail now lives
in the dedicated DevOps pages below so the docs stay current as workflows change.

## Read Next

* [DevOps & Deployment Overview](/build/devops/overview)
* [Environments & Release Flow](/build/devops/environments-release-flow)
* [Web Docker Deployment](/build/devops/web-docker-deployment)
* [GitHub Actions Runbook](/build/devops/github-actions-runbook)
* [Secrets & Configuration](/build/devops/secrets-and-configuration)

## Current CI/CD Shape

Tuturuuu currently automates:

* Vercel preview deployments for non-`production` branches
* Vercel production deployments from the `production` branch
* Independent Vercel preview and production deployments for satellite apps such as `apps/cms`
* Affected-app gating for Vercel deployments before dependency install, build, or deploy work
* Supabase staging migrations driven from `main` and production migrations driven from `production`
* Docker parity and image validation for the self-hosted web runtime
* Modal deployment for `apps/discord`
* Mobile build artifact generation
* Package publishing to npm
* Quality, lint, type, test, and security checks

## Important Repo Conventions

* For most authored changes, run the applicable check, lint, test, and build
  workflows in CI and verify their results on the exact commit. Focused local
  checks help find problems quickly but do not replace that CI evidence. If a
  workflow queue is demonstrably stuck, record the pending jobs and local
  results; resume the exact-commit CI checks before claiming release readiness.
* `ci-check.yml` reads `tuturuuu.ts` and can disable an individual workflow centrally.
* Vercel workflows use `tuturuuu.ts` app metadata and workspace `workspace:*` dependency closures to run only affected app deploys.
* `bun.lock` changes run all Vercel app deploys because lockfile ownership is ambiguous without a source or manifest path.
* Manual `workflow_dispatch` runs enabled workflows even when changed paths would otherwise be unaffected.
* Production Vercel workflows cancel superseded per-app runs only for newer
  `production` pushes. A `main` commit or manual recovery run never cancels an
  active production deployment.
* The external-app internal-package build uses the same cancel-superseded policy, so rapid pushes cannot finish as green no-op builds.
* Database migrations are not treated the same as app deploys; staging and production each have explicit prerequisite logic, with staging now sourced from `main`.
* Docker changes are guarded by `docker-setup-check.yaml`, including dev and production image builds.

## When To Use This Page

Use this page for orientation. Use the DevOps pages for the runbook you actually need
while operating the system.

### Learn preview build validation

The trusted manual `vercel-preview-learn.yaml` workflow builds the checked-out
`preview_ref` with a 35-minute timeout and the existing two-task Turbo limit.
It records a `build` marker using `git rev-parse HEAD`, rather than the main
workflow dispatch SHA. It does not deploy the artifacts. Learn build markers
cannot advance the successful deployment baseline; existing Platform marker
compatibility remains unchanged. A successful build proves compilation, while
actual-device validation and deployment are separate gates.

Focused checks: `node --test scripts/ci/learn-preview-build.test.js
scripts/ci/github-deployment-markers.test.js scripts/ci/release-workflows.test.js`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.