# 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 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](#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[​](#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).

## Install vs push on production[​](#install-vs-push-on-production "Direct link to Install vs push on production")

Both commands deploy code, but they serve different purposes:

| Command   | What it does                                 | When to use                                         |
| --------- | -------------------------------------------- | --------------------------------------------------- |
| `install` | Compiles and uploads in one atomic operation | Preferred for production - consistent and reliable  |
| `push`    | Uploads raw source files to AppCode          | Use 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[​](#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. 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.

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

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