deploy: alpine runtime image with the daemon and CLI onlyv0.1.45

1 files changed, 16 insertions, 13 deletions

diff --git a/docs/DEPLOY.md b/docs/DEPLOY.md
index 7694add..ed105f8 100644
--- a/docs/DEPLOY.md
+++ b/docs/DEPLOY.md
@@ -56,8 +56,6 @@ Normal deploys build an image and recreate the container. While developing,
 `scripts/deploy.sh --dev` skips the image entirely:
 
 - the gate (`make` + `make test`) still runs locally,
-- on an architecture mismatch the binaries are cross-compiled here
-  (`deploy/Dockerfile.cross`, ~20 s on a PC),
 - the binaries are copied into the running container with `docker cp`,
 - the daemon is reloaded with `SIGHUP`, which re-execs the binary in place
   (in-memory sessions are lost, clients reconnect),
@@ -65,7 +63,9 @@ Normal deploys build an image and recreate the container. While developing,
 
 No image is built and the container is not recreated; a later normal deploy
 replaces the copied binaries. Use a descriptive tag, e.g.
-`scripts/deploy.sh --dev v0.2.0-rc1`.
+`scripts/deploy.sh --dev v0.2.0-rc1`. Hot reload requires the host to share
+the dev machine's architecture; on a mismatch `--dev` falls back to a full
+remote build.
 
 ## Deploying upgrades
 
@@ -87,11 +87,12 @@ The script:
 5. on failure, puts the previous `BOKF_TAG` back and rolls back to the image
    that is still loaded on the host.
 
-Cross-architecture builds are automatic: `uname -m` is compared over SSH and
-a mismatch switches to a remote build. Override with `BOKF_BUILD=local` or
-`BOKF_BUILD=remote` (also settable in `.env`). A remote build pulls the
-Debian base image inside a container, so the host needs outbound network
-access but still no toolchain.
+Architecture mismatches are automatic: `uname -m` is compared over SSH and a
+mismatch switches to a remote build of the same Alpine image (compiled inside
+the host's Docker, so the host still needs no toolchain). Override with
+`BOKF_BUILD=local` or `BOKF_BUILD=remote` (also settable in `.env`). The
+runtime image is Alpine and carries `bokfd` + `bokfctl` only; the ncurses TUI
+is a frontend and never shipped.
 
 Tags are `git describe` output unless passed. Tag releases (`v*`) so rollback
 and support have meaningful versions. The rollback image must still exist on
@@ -121,17 +122,19 @@ to `main`. The normal `scripts/deploy.sh` flow does not need any of this.
 
 ## Clients
 
-Run clients inside the container — no host toolchain needed:
+The image ships only the daemon and `bokfctl`, which covers the healthcheck
+and quick admin calls:
 
 ```sh
-docker compose exec bokfd bokftui                    # interactive TUI
 docker compose exec -e BOKFD_PASSWORD='<pw>' bokfd \
     bokfctl --user admin fiscal_year.list
 ```
 
-The clients honor `BOKFD_SOCKET`; a host-installed client can also point at
-`var/run/bokfd.sock`, but that file is owned by uid 10001, so the host user
-must be in that group (or use `sudo`).
+The TUI (`bokftui`) is a frontend: build it from source on the machine you sit
+at (`make bokftui`, needs libncursesw) and point it at the host, normally the
+TLS listener. A host-installed client can also point at `var/run/bokfd.sock`,
+but that file is owned by uid 10001, so the host user must be in that group
+(or use `sudo`).
 
 The TUI remembers the server and user (never the password) in
 `$XDG_CONFIG_HOME/bokf/tui.conf` (`~/.config/bokf/tui.conf`), written after