Skip to main content

Production deployment

Deploying to production requires extra care. This guide covers the pre-deploy checklist, multi-environment configuration, deploy users, and rollback procedures.

Pre-production checklist​

Complete these four steps before every production deployment:

  1. Verify on dev first - deploy to the development environment and confirm everything works. Never push untested code directly to production.
  2. Pull the prod state - run npx comind pull app-your-task against the production environment to check for web UI edits that haven't been committed to Git yet. Resolve any differences before deploying.
  3. Use a deploy user - deploy through a dedicated Comind.work user account so the audit trail clearly shows automated or planned deployments (see deploy user setup below).
  4. Know your backup position - confirm you can identify the last known-good state in Git so you can roll back quickly if needed.

Multi-environment configuration​

Create a separate environment file for production:

cp .config/dev.env .config/prod.env

Edit .config/prod.env with your production credentials and URL. Then switch environments by commenting/uncommenting in your root .env file:

.env
# COMIND_ENV=dev
COMIND_ENV=prod

To switch back, comment out prod and uncomment dev. For full details on environment switching, see environment variables.

Install vs push on production​

Both commands deploy code, but they serve different purposes:

CommandWhat it doesWhen to use
installCompiles and uploads in one atomic operationPreferred for production - consistent and reliable
pushUploads raw source files to AppCodeUse when you need source traceability on the server

For most production deployments, install is the safer choice. It ensures the deployed code is compiled from a known state.

Deploy user setup​

Create a dedicated Comind.work user for automated or scripted deployments. This keeps the audit trail clean - you can immediately tell whether a change came from a human editing in the web UI or from a planned deployment.

To set up a deploy user:

  1. Create a new user in your Comind.work workspace (e.g., deploy-bot or ci-deploy)
  2. Grant the user the necessary app permissions
  3. Generate an auth token for that user
  4. Use the token in your production .config/prod.env:
.config/prod.env
COMIND_SECRET_AUTH_CODE_MANAGEMENT=deploy-user-token-here
COMIND_BASE_URL=https://YOUR-ORG.comindwork.com
COMIND_API_V1_URL=https://api.comindwork.com
tip

Signed commits on the prod branch are still required regardless of which user runs the deploy. See the git workflow for branching rules.

API version mismatch warnings​

You may see API version mismatch warnings when deploying. On development environments, these are safe to ignore - they indicate a minor version difference between the CLI and the server API. On production, check that the warning doesn't indicate a breaking change before proceeding.

Rollback​

If a production deployment causes issues:

  1. Identify the last known-good commit in Git
  2. Check out that commit or reset to it
  3. Pull the current production state to preserve any data changes: 
    npx comind pull app-your-task
  4. Re-install from the known-good code: 
    npx comind install app-your-task

The combination of Git history and the pull command gives you a clear path back to a working state.