Skip to main content
HMIS uses three environments. Promote the same tested commit from local development to staging and then to production.

​
Promotion contract

1

Validate locally

Run the affected automated tests, build the frontend, and exercise the changed workflow with synthetic data.
2

Deploy the exact commit to staging

Run migrations, targeted seeders, smoke tests, and any laboratory or radiology acceptance cycle required by the change.
3

Approve the release

Record the commit, migration status, backup identifier, acceptance evidence, operator, rollback owner, and maintenance window.
4

Promote to production

Deploy the approved commit without rebuilding from an unreviewed branch. Follow the release runbook.

​
Separation requirements

  • Use different databases, volumes, domains, API tokens, APP_KEY values, mail destinations, and device credentials in every environment.
  • Do not restore production data into local or staging unless the data is irreversibly de-identified and the transfer is approved.
  • Prevent staging mail and notifications from reaching real patients or staff.
  • Give staging integrations distinct facility, instrument, PACS, and OIE identifiers.
  • Preserve the production APP_KEY; losing or replacing it can make encrypted application data unreadable.
Never copy a local .env into Dokploy. Build the staging and production variable sets from the documented matrix and generate new secrets for each environment.

​
Release evidence

Retain the following with each production deployment:
  • Approved commit or image identifier
  • Database migration status before and after deployment
  • Pre-release backup identifier and restore status
  • Automated test and staging acceptance results
  • Production smoke-test results
  • Known issues and rollback decision point
  • Names of the release operator and clinical approver