refactor: phase 2 production requirements

docs/deployment-vm.md

@@ -0,0 +1,63 @@
+# Deploying on a VM
+
+This service is meant to run as a small Go process on a VM or VPS.
+
+A simple setup is enough:
+- the Go binary
+- a local `config.yaml`
+- DCMTK binaries
+- MicroDicom files
+- a reverse proxy in front
+- a `systemd` service to keep the process running
+
+## Suggested layout
+A plain layout is easier to operate:
+
+- app directory: `/opt/dicom-iso`
+- binary: `/opt/dicom-iso/mkiso-server`
+- config: `/opt/dicom-iso/config.yaml`
+- logs: `journalctl` through `systemd`
+- temp work: `/tmp` or another writable local path
+
+## What must exist before start
+The service needs:
+- working DCMTK binaries
+- working PACS access
+- working patient API access
+- working CD publisher access
+- a real MicroDicom directory
+- a writable temp directory
+- a free port range for `storescp`
+
+## Build note
+The build environment cannot depend on public internet access.
+That means the binary must be built through an approved offline-friendly path.
+
+## Running the service
+The simplest production shape is:
+- build the binary
+- copy the binary to the VM
+- place `config.yaml` next to it
+- install the `systemd` unit
+- start the service
+- put nginx in front of it if legacy paths are still needed
+
+## Rollback
+Keep rollback simple:
+- keep the previous binary
+- keep the previous config
+- restart the old version through `systemd`
+
+## First checks after deploy
+After the service starts, verify:
+- the process is running
+- the configured port is listening
+- `/api/health` responds
+- DCMTK paths are valid
+- MicroDicom path is valid
+- one real accession works end to end
+
+## Operational note
+Real secrets must stay out of git.
+Only `config.example.yaml` belongs in the repo.
+The real `config.yaml` should be created on the VM.