Skip to content

CI/CD workflow

Principle

Every change is validated before it reaches main; every production deployment can be traced to a reviewed Git revision. CI validates code. Dokploy builds and runs the production deployment.

Pull-request CI

All production repositories run a GitHub Actions workflow on pull requests. For Node.js monorepos, the workflow must run these commands in order:

corepack enable
pnpm install --frozen-lockfile
pnpm format:check
pnpm lint
pnpm typecheck
pnpm test
pnpm build

The workflow should also build the production Docker image without pushing it. This catches Dockerfile and workspace-pruning mistakes before merge.

For non-Node repositories, provide equivalent formatting, static analysis, test, build, and container-build validation.

Merge and deployment

  • CI is required before merge to develop or main.
  • A pull request from develop to main is the production release.
  • Dokploy deploys from main only, using its Git provider integration or a deployment webhook.
  • The deployment must record the Git commit SHA in the Dokploy deployment history, image label, or release notes.
  • Do not deploy a local checkout, an unreviewed branch, or a manually edited production container.

Database migrations

Use a dedicated migration command, never an ad-hoc command typed into a production shell. The migration workflow must be stated in the README and must be safe to repeat or safely fail.

For a destructive schema change, use an expand-and-contract approach:

  1. add the new schema while the old schema remains usable;
  2. deploy compatible application code;
  3. migrate and verify data; and
  4. remove the old schema only in a later release.

Deployment verification

After each production deployment, the deployer checks:

  • Dokploy reports a healthy deployment;
  • the service health endpoint responds successfully;
  • the primary customer journey works; and
  • application logs contain no unexpected startup or migration errors.

If any check fails, roll back to the last known-good deployment and record the incident in the pull request or work tracker.