Files
home-information/docs/Deployment.md
Tony C 52999d9e99 Make docker compose the ongoing management surface (#382) (#394)
* Add docker compose templates and env-var drift check (#382)

Phase 1 of issue #382 (docker compose support):

Repo-root templates for users integrating HI into their own compose stack:
 - docker-compose.example.yml — published image, container_name: hi, $HOME/.hi
   volume defaults; no healthcheck stanza (Dockerfile's HEALTHCHECK applies)
 - local.env.example — generated from env-generate.py --example; preamble
   explicitly warns install.sh users not to drop it at ~/.hi/env/local.env

Drift prevention across the three env-var sources:
 - install.sh gains --list-env-vars, extracting names from its own heredoc via
   a unique terminator (INSTALL_ENV_FILE_EOF) so the listing cannot drift from
   what the script actually writes
 - env-generate.py gains a SETTING_SECTIONS canonical declaration that seeds
   self._settings_map and drives --example output; validate_settings() runs
   before _write_file() and fails the run on undeclared keys or unset values
 - deploy/env-drift-check.sh compares the three name sets and prints a clean
   labeled diff on mismatch
 - Wired into make env-drift-check, make check, and a CI step in
   django-tests.yml

install.sh SECRET_KEY charset narrowed to exclude characters that can confuse
docker compose's env_file parser (\", ', \\, \$, #, =, \`).

* Add docker compose path to install.sh and update.sh (#382)

Phase 2 of issue #382 (docker compose support):

install.sh:
 - check_docker_compose probes `docker compose version` (no install offer,
   no platform branching)
 - create_compose_file writes a fully-resolved compose file to
   ~/.hi/docker-compose.yml with container_name: hi so legacy
   `docker logs/stop/start hi` work identically across both code paths
 - Existing compose file is backed up to .BAK.<timestamp> before overwriting
   (protects hand-edits for reverse-proxy labels, custom networks, etc.)
 - start_container branches on HAS_COMPOSE: compose up -d when available,
   original docker run when not
 - show_success adds docker restart hi and the update.sh canonical update path

update.sh:
 - Same check_docker_compose pattern
 - update_via_compose runs `docker compose pull` then `up -d`
 - Branches when both compose is available AND ~/.hi/docker-compose.yml
   exists (pre-Phase-2 installs stay on the legacy recreation flow)

Container is named `hi` on both paths so post-install management commands
documented in `docs/Installation.md` work uniformly regardless of which
code path created the install.

* Split Installation.md into a simple-user doc and a Deployment.md (#382)

Phase 3 of issue #382 (docker compose support):

docs/Installation.md (290 → 123 lines):
 - Quick Installation → Next Steps (moved from the bottom) → Managing your
   installation → Updates → Environment Variable Changes → Removing your
   installation → Troubleshooting
 - "Managing your installation" fills the post-install management gap and
   uses only legacy `docker logs/stop/start/restart hi` commands, which work
   for both install-time code paths (the compose file is generated either
   way and container_name: hi is set on both paths)
 - Manual Installation section removed entirely; docs/dev/Setup.md already
   covers `make docker-build/run` for the from-source/developer audience
 - More Help points users at Deployment.md for advanced topics

docs/Deployment.md (new, 87 lines):
 - Network Access Configuration
 - Auto-Start on Reboot
 - User Management
 - Using docker compose directly (compose verbs as an equivalent alternative
   to legacy docker commands)
 - Integrating into your own compose stack (with the env-file format gotcha
   spelled out: no export, no shell quoting, no ${VAR} interpolation)
 - Pointer to the Integrations Guide

README.md:
 - "Need more control?" updated to point at both Installation.md and
   Deployment.md
 - Resources → Users list adds Deployment Options

* Code-review polish and add env-var ritual doc (#382)

deploy/env-generate.py:
 - validate_settings() moved from generate_env_file() into _write_file()
   so any future code path that writes the env file is guarded
 - Spacing fixes for project convention (inner spaces in update( { ... } ),
   sorted( extra ) / sorted( missing ))
 - "extra" error wording hints at typo in __init__ overlay as a possible
   cause, not just "add to SETTING_SECTIONS"
 - Drive-by colon spacing on the pre-existing HI_SUPPRESS_AUTHENTICATION
   overlay key

docs/dev/shared/environment-variables.md (new):
 - Documents the 4-place ritual when adding an env var dependency:
   EnvironmentSettings (server.py), SETTING_SECTIONS + value assignment
   (env-generate.py), install.sh heredoc, regenerated local.env.example
 - Explains what make env-drift-check covers (three sources) and
   what it deliberately does not (server.py — field names diverge by
   design; other os.environ.get callers — caught only by review)

src/hi/environment/server.py:
 - Pointer comment on EnvironmentSettings dataclass referencing the new doc

* Move dev init scripts into dev/ and make them self-locating

Two top-level scripts (init-env-dev.sh, init-claude.sh) carried hardcoded
personal paths that made them effectively unusable for other contributors,
and their visibility at the repo root suggested otherwise. Moved into
dev/ and rewritten to be portable:

dev/init-env-dev.sh:
 - Computes PROJ_ROOT via BASH_SOURCE so absolute paths to
   venv/bin/activate and .private/env/development.sh resolve regardless
   of the caller's working directory
 - Header comment now states the script must be sourced (the `return 1`
   failure paths only behave correctly when sourced)

dev/init-claude.sh:
 - Self-locates PROJ_ROOT the same way; the previous `cd ~/proj/hi`
   personal hardcode is gone
 - `export PATH="~/.local/bin:..."` → `export PATH="$HOME/.local/bin:..."`
   (tilde inside double quotes does not expand)
 - `gh auth status --hostname "$host"` → `--hostname github.com` (the
   prior `$host` was undefined)

Unrelated to issue #382; bundled on this branch for convenience.
2026-06-01 21:36:12 -05:00

3.8 KiB

Home Information Logo

Deployment Options

Production configuration and self-hosting options beyond a single-machine localhost install. This guide assumes you already have a working installation per the Installation Guide.

Network Access Configuration

By default, the app only accepts requests addressed to localhost. To access it from another device on your network (by IP address or hostname), edit ~/.hi/env/local.env and add the URLs you'll use:

# Example: accessing via IP address and hostname
HI_EXTRA_HOST_URLS="http://192.168.1.100:9411 http://home-server:9411"

Multiple URLs are space-separated. After saving, restart the app: docker restart hi.

If you see Invalid HTTP_HOST header errors in the logs, this is the setting you need.

Auto-Start on Reboot

The Docker container is configured to restart automatically (--restart unless-stopped), but Docker itself needs to start on boot:

macOS (Docker Desktop):

Docker Desktop → Settings → General → "Start Docker Desktop when you log in"

Linux (Ubuntu/systemd):

# Check if enabled
systemctl is-enabled docker

# Enable if needed
sudo systemctl enable docker

User Management

If you enabled user authentication, create user accounts via the Django admin interface:

  1. Sign in at http://localhost:9411/admin/ using:

    • Email: DJANGO_SUPERUSER_EMAIL (from your env file)
    • Password: DJANGO_SUPERUSER_PASSWORD (from your env file)
  2. Add users at: http://localhost:9411/admin/custom/customuser/add/

Requirements: Email configuration must be working (users receive "magic code" login links).

Using docker compose directly

If you already use docker compose to manage your services, you may prefer compose verbs over the docker logs hi / docker stop hi commands documented in the Installation Guide. They are equivalent — install.sh generates a compose file at ~/.hi/docker-compose.yml, so you can use either set of commands interchangeably.

cd ~/.hi
docker compose ps          # status
docker compose logs -f     # follow logs
docker compose restart     # restart
docker compose down        # stop and remove the container
docker compose up -d       # bring it back
docker compose pull && docker compose up -d   # update to latest image

If docker compose was not installed when you first ran install.sh, you can install it later and start using these commands immediately — the compose file is written either way.

Integrating into your own compose stack

If you already manage your services with a single docker compose file (or directory of files), you can run Home Information from that stack instead of using install.sh.

Reference files in the repository root:

Copy both files into your stack, fill in the placeholder values in local.env, then start the app with your usual compose commands.

Important format note: docker compose's env_file parser is not the same as shell-sourced env files. No export, no shell-style quoting (single or double quotes), no ${VAR} interpolation. local.env.example is in the correct format; do not adapt a shell-sourced env file by hand without removing those features.

Integrations

Connect Home Information with your existing home automation, security and document systems. See the Integrations Guide for setup instructions.