> ## Documentation Index
> Fetch the complete documentation index at: https://thinkexinc-ff642c69-codex-filerouter-dogfood.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Deployments

> CI, staging, and production deployment shape.

ThinkEx deploys from GitHub Actions to Cloudflare Workers. Deploy, migration, and secret-management commands are operational actions and should not be run casually from a local checkout.

## Branches and Environments

| Environment | URL                           | Worker            | Trigger                                                              |
| ----------- | ----------------------------- | ----------------- | -------------------------------------------------------------------- |
| Production  | `https://thinkex.app`         | `thinkex`         | Successful CI run on `main`, or manual workflow dispatch from `main` |
| Staging     | `https://staging.thinkex.app` | `thinkex-staging` | Push to `staging`, or manual workflow dispatch                       |

## CI

The `CI` workflow runs on pull requests, pushes to `main`, and manual dispatch.

On pull requests (and non-`main` pushes), it installs with Vite+ and runs:

```bash theme={null}
vp run verify
```

`verify` runs the repo's check, test, and build tasks using Vite Task caching. When changes go through a pull request, the `validate` check must be green before merge.

The separate `React Doctor` workflow runs on pull requests and pushes to `main`. It scans changed React files on pull requests, posts inline diagnostics, and records the React Doctor score without folding those comments into the main Vite+ verification job.

## Production Deploy

Production deploy trusts PR `validate` when present and ships the production artifact: build, remote D1 migrations, then Worker deploy. Concurrent production deploys queue instead of cancelling mid-flight. Direct pushes to `main` are still allowed.

```bash theme={null}
vp run build:production
vp run db:migrate
vp run deploy:worker
```

## Staging Deploy

The staging workflow follows the same ship shape against staging bindings and routes:

```bash theme={null}
vp run build:staging
vp run db:migrate:staging
vp run deploy:worker:staging
```

<Warning>
  Remote migrations and deploy commands affect shared environments. Run them only when you are intentionally doing release work.
</Warning>

## Secrets

Runtime and deploy secrets are synced into GitHub Actions secrets from Infisical. Production and staging workflows require Cloudflare credentials, PostHog variables, and the runtime secrets declared by the Worker configuration.

Direct workspace uploads additionally require bucket-scoped R2 Object Read & Write credentials in `R2_ACCESS_KEY_ID` and `R2_SECRET_ACCESS_KEY`, `R2_ACCOUNT_ID`, and an independent random `WORKSPACE_UPLOAD_TOKEN_SECRET` for completion claims. Configure browser PUT access from the checked-in policies:

```bash theme={null}
wrangler r2 bucket cors set thinkex-workspace-kernel-files-staging --file config/r2/cors.staging.json
wrangler r2 bucket cors set thinkex-workspace-kernel-files --file config/r2/cors.production.json
```

After inspecting existing lifecycle rules, add a one-day expiry for abandoned direct-upload objects in each bucket:

```bash theme={null}
wrangler r2 bucket lifecycle add thinkex-workspace-kernel-files-staging expire-abandoned-workspace-file-uploads workspace_file_uploads/ --expire-days 1
wrangler r2 bucket lifecycle add thinkex-workspace-kernel-files expire-abandoned-workspace-file-uploads workspace_file_uploads/ --expire-days 1
```

<Warning>
  CORS `set` replaces the bucket's current CORS policy. Reconcile the checked-in policy with any existing rules before applying it.
</Warning>