Skip to main content
Every production release must have a tested staging deployment, a pre-release recovery point, a named operator, and a named rollback authority.

​
Release record

Record the following before the maintenance window:
  • Approved commit and source branch
  • Application, migration, dependency, integration, and configuration changes
  • Staging test evidence
  • Expected downtime and communication owner
  • Backup identifier and restore verification date
  • Migration and targeted-seeder commands
  • Smoke tests and clinical workflow checks
  • Rollback decision deadline and owner

​
Production release

1

Confirm the recovery point

Create and verify the pre-release database and volume backup. Do not proceed when the most recent restore evidence is missing or the off-site upload failed.
2

Enter maintenance mode

In the app service terminal:
Store the generated bypass URL only in the release record and share it with the release team through the approved secret channel.
3

Deploy the approved commit

Deploy through Dokploy and watch build, proxy, application, queue, scheduler, and database logs. Keep RUN_MIGRATIONS=false.
4

Run migrations once

Stop and escalate if a migration fails. Do not repeatedly rerun a partially applied data migration without reviewing its state.
5

Refresh permissions and approved integration data

Run PacsDemoSeeder only when the approved release requires the supplied PACS endpoint update:
6

Restart background work and caches

7

Reapply the simulator control

Stop mock-analyzer and mock-modality, confirm neither has a domain, and check the firewall. A Compose deployment can restart them.
8

Run pre-open smoke tests

Test /up, administrator and staff authentication, branch selection, a database write, file storage, queue processing, scheduler state, mail, and every affected clinical or integration workflow.
9

Leave maintenance mode

Repeat the external health and authentication checks without the maintenance bypass.
10

Observe and close

Monitor errors, latency, queue depth, resource use, storage, and integrations through the agreed observation window. Attach results to the release record.

​
Rollback decision

Rollback the application when the candidate cannot pass health, authentication, data integrity, or critical workflow checks within the approved window. Stop traffic first and retain logs and failed-state evidence.
Select the previous tested deployment or commit in Dokploy, redeploy it, clear caches, restart the queue, stop simulators, and repeat smoke tests.
Never regenerate APP_KEY, delete volumes, run migrate:fresh, or restore a database over the live database as a rollback shortcut.

​
Post-rollback reconciliation

  • Compare transactions created during the release window with source documents and connected systems.
  • Reconcile queued, failed, duplicated, or externally acknowledged messages.
  • Confirm the exact restored or retained database point.
  • Record the incident timeline, decision, user impact, corrective action, and next release controls.