[BUG] Secrets/environment variables stored in Dockhand DB are not available during Docker-native restarts (host reboot, crash recovery)

[aruj0]

Description

When an environment variable is converted to a secret via the Dockhand UI, the value is encrypted and stored in Dockhand's SQLite database (stack_environment_variables table with is_secret=1). This works correctly for Dockhand-initiated operations (deploy, stop, restart via the UI).

However, when Docker itself restarts a container — via restart: unless-stopped after a crash or host reboot — Docker Compose resolves ${VAR} references from the .env file on disk, which doesn't exist (or doesn't contain the secret). The container starts with empty environment variables and crash-loops.

This is a critical issue because restart: unless-stopped is the standard way to ensure containers survive reboots, and it's completely broken for any stack with Dockhand-managed secrets.

Related to #371 which fixed the Dockhand-side operations, but this is a different code path — Docker's own restart mechanism bypasses Dockhand entirely.

Steps to reproduce

1. Deploy a stack with an environment variable referenced in compose.yaml (e.g., TUNNEL_TOKEN=${TUNNEL_TOKEN})
2. In the Dockhand UI, click the button to convert that variable to a secret
3. Verify the stack works when deployed through Dockhand
4. Simulate a crash: docker stop <container> — Docker's restart policy brings it back, but the env var is now empty
5. Alternatively, reboot the host — same result

Logs

# Container is in a restart loop
$ docker ps -a --filter name=cloudflared
NAMES         STATUS                            IMAGE
cloudflared   Restarting (255) 37 seconds ago   cloudflare/cloudflared:latest

# Env var is empty
$ docker inspect cloudflared --format '{{json .Config.Env}}'
["TZ=Europe/London","TUNNEL_TOKEN=","PATH=..."]

# The value exists in Dockhand's DB, encrypted
$ sqlite3 /opt/data/dockhand/db/dockhand.db \
  "SELECT key, is_secret FROM stack_environment_variables WHERE stack_name='cloudflared'"
TUNNEL_TOKEN|1

Browser logs

N/A — this is a backend/Docker-level issue, not a UI issue.

Please confirm the following

• I have already searched for relevant existing issues and discussions before opening this report.
• I have updated the title field above with a concise description.

[jotka]

hi @aruj0 i don't think it would be possible to keep the "secrets are never written to disk" approach and allow Docker's own restart mechanism.