# 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`

If you do not manage these assets globally on the VM, you can stage them locally first:

```bash
scripts/setup-dcmtk.sh --source-dir /path/to/dcmtk/bin --install-dir /opt/dicom-iso/dcmtk-bin
scripts/setup-microdicom.sh --source-dir /path/to/microdicom --install-dir /opt/dicom-iso/microdicom
```

## 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.