Skip to main content
Perform the complete sequence in staging before production. Record every command, operator, timestamp, result, and deviation in the deployment record.

​
Before deployment

  • Approved commit and change record
  • Environment variables reviewed by two authorized people
  • DNS and TLS routes prepared
  • Persistent volumes identified
  • Off-site backup repository tested
  • Maintenance, rollback, clinical, and security owners available
  • RUN_MIGRATIONS=false
1

Create the initial recovery point

Capture the server or volume baseline and record its identifier. Even an empty first deployment needs a known recovery point for infrastructure configuration.
2

Deploy the approved commit

Trigger the Dokploy Compose deployment. Wait for postgres to become healthy and app, queue, and scheduler to remain running.Do not accept clinical traffic yet.
3

Stop production simulators

Stop mock-analyzer and mock-modality in Dokploy. Confirm neither has a domain or published network path. Repeat this check after every Compose redeployment.
4

Run migrations exactly once

Open a terminal for the app service:
5

Seed foundational data explicitly

Run the required seeders by class and in this order:
Review the placeholder organization, branch, departments, clinics, payers, and services before go-live.
6

Create the first administrator

Run the interactive command so the password is not placed in shell history:
Enter the named administrator’s real work email and a unique temporary password through the prompt.
7

Assign the super-administrator role

Select the user created in the previous step. Do not share this account.
8

Restart and verify background work

Confirm op-visits:close-expired is scheduled at 00:01 and the queue and scheduler containers remain running.
9

Clear and rebuild production caches

10

Run smoke tests

Verify:
  • https://{{HMIS_DOMAIN}}/up returns 200.
  • The administrator can sign in at /admin.
  • The administrator changes the temporary password and enables 2FA.
  • Branch selection and the main dashboard load.
  • Database writes, queue processing, scheduler state, storage, and mail work.
  • No repeating errors appear in application, queue, scheduler, proxy, or database logs.
Never run php artisan db:seed without --class in production. The broad seeder creates a known admin@example.com / password account.

​
Integration-specific release steps

Enable integrations only after the core HMIS checks pass. Use Optional integrations for OIE, Orthanc, OHIF, API token, channel, endpoint, and acceptance requirements.

​
Deployment evidence

Retain the commit, migration output, targeted seeder output, first-administrator identity, stopped simulator state, health results, backup identifier, log review, and approval to begin initial configuration.