# 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[​](#pre-production-checklist "Direct link to Pre-production checklist")

Complete these three 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. **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](#deploy-user-setup) below).
3. **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[​](#multi-environment-configuration "Direct link to 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](/developer-guide/getting-started/environment-variables.md).

## Deploy user setup[​](#deploy-user-setup "Direct link to 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](/developer-guide/getting-started/git-workflow.md) for branching rules.

## API version mismatch warnings[​](#api-version-mismatch-warnings "Direct link to 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[​](#rollback "Direct link to 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. Re-install from the known-good code:
   <!-- -->
   ```
   npx comind install app-your-task
   ```

Git history is your rollback mechanism - the `install` command always deploys whatever is currently in your working tree.

## Related[​](#related "Direct link to Related")

* [CLI reference](/developer-guide/reference/cli-reference.md) - full command syntax for `install` and the other CLI commands
* [Git workflow](/developer-guide/getting-started/git-workflow.md) - branching strategy and deploy workflow
* [Testing apps](/developer-guide/how-to/advanced/testing-apps.md) - run automated tests before deploying to production