lhumina_code/hero_demo
0
0
Fork 0
Code Issues 60 Pull requests Projects Releases 2 Packages Wiki Activity Actions

Provision fresh herodemo on DO droplet using lab download-install flow #66

New issue
Closed
opened 2026-05-19 18:03:51 +00:00 by mik-tf · 1 comment
mik-tf commented 2026-05-19 18:03:51 +00:00
Owner
Copy link

Summary

Provision a fresh herodemo on a DigitalOcean droplet using the canonical lab build/install flow (download prebuilt musl-x86_64 binaries from each repo's latest Forgejo release — no source compile on the VM). Replace the dead TFGrid herodemo at herodemo.gent01.grid.tf (contracts cancelled 2026-05-19, see below). Keep the older hero.gent04.grid.tf deployment untouched as the fallback during transition.

Why now

The 2026-01-16-vintage TFGrid herodemo VM accumulated 2–3 weeks of binary drift (most services on May 1 / May 6 builds) and hit the home#202 supervisor-vs-socket drift pattern multiple times in one inspection. A 2026-05-19 attempt to upgrade in-place to hero_proc_server v0.6.0 exposed:

  1. New v0.6.0 daemon's spec_json format is incompatible with the v0.4.4 service registry (schema identical, content not). Old DB rows are wiped on first start.
  2. Old action scripts hardcode old CLI flags (e.g., hero_router --port 9988); new binaries reject those (now --bind <ADDR:PORT>).
  3. Many service.toml [[env]] blocks lack PATH_ROOT — daemons panic at paths.rs:38:32 per Lesson #19 / s125 (mycelium_network PR #48 added this exact fix to 4 daemons).
  4. No source-of-truth registration script exists on either VM or workstation. nutools/modules/services/ in hero_skills HEAD has been gutted to a single file; bootstrap_droplet_source.sh clones source but does not register services.

Net: upgrading in-place is more risky than a fresh provision. The fresh provision uses today's latest Forgejo releases — which we just populated for the full canonical demo set (~20 repos).

Cancelled / contract state

Cancelled on 2026-05-19 via tfcmd cancel contracts:

  • herodemo (5 contracts): net 2091015 + 2091016, vm 2091017, gateway 2091019, name 2091018 → herodemo.gent01.grid.tf is GONE
  • herozero (2 contracts) + heroci (5 contracts) — earlier in the same session

Kept on TFGrid:

  • hero (4 contracts: net 2070724, vm 2070725, gateway 2070727, name 2070726) → hero.gent04.grid.tf — DO NOT CANCEL until DO droplet is green. This is the only Hero deploy left during the transition window.

New target architecture

Layer Old (cancelled) New
Infra TFGrid VM via tfgrid-compose DigitalOcean droplet (existing do_droplet_create.sh + cf_dns_set.sh)
Binaries Source-built on VM via hero_builder Forgejo latest release downloads via lab build <repo> --download --install
Supervisor hero_proc_server v0.4.4 hero_proc_server v0.6.0 (current latest)
Service registration Manual after bootstrap Canonical bootstrap script that registers each service from its --info --json output
Auth gate nginx basic-auth nginx basic-auth (unchanged)
Domain herodemo.gent01.grid.tf (TFGrid name contract) <name>.gent01.grid.tf or DO-managed FQDN; Cloudflare/etc. proxying as needed

Plan

Phase 1 — bootstrap script rework

Update deploy/cloud_vm/scripts/bootstrap_droplet_source.sh (or write a new bootstrap_droplet_releases.sh) to:

  1. Install base packages (existing logic)
  2. Install lab (one-line install — depends on hero_skills#268 install.sh fix)
  3. Run lab user init --root ~/hero to populate init.sh with PATH_ROOT/PATH_VAR/PATH_BUILD/PATH_CODE/HERO_SOCKET_DIR
  4. For each repo in the canonical demo set: lab build <repo> --download --install --platforms linux-musl-x86_64 — pulls today's latest binaries to ~/hero/build/bins/, then copies them with platform-suffix-stripped names to ~/hero/bin/
  5. Start hero_proc_server in screen with the full env exported
  6. Register all 22 services via a generated script that walks each ~/hero/bin/<bin> and calls --info --json, then uses hero_proc service add + hero_proc service add-job with proper script/env/health-check/restart-policy
  7. Start all services in dependency order
  8. Drop nginx + basic-auth config (unchanged from current herodemo)
  9. Configure DNS (Cloudflare via cf_dns_set.sh)

Phase 2 — DO droplet provisioning

  • Size: 16 CPU / 32 GB RAM / 200 GB disk (matches old herodemo specs)
  • Region: nearest to user base
  • Use existing deploy/cloud_vm/scripts/do_droplet_create.sh for create
  • One-shot bootstrap: scp then ssh ... bash bootstrap_droplet_releases.sh

Phase 3 — verification

  • Browser smoke test: https://<new-fqdn>/hero_os/ui loads past the WASM shell
  • All 22 services healthy per hero_proc service list
  • All per-domain hero_osis_* sockets respond 200 to /health
  • hero_router log shows N services scanned, ≥95% healthy
  • Cancel hero.gent04.grid.tf only AFTER new deploy is green for 24h+

Phase 4 — clean-up

  • Strip the bootstrap_droplet_source.sh clone-and-source-build path (kept as _source variant in the script archive) once _releases is proven
  • Update CLAUDE.md "herodemo VM" table with the new FQDN/IP
  • Update memory/project_demo_service_set.md if the canonical set drifts

Gotchas — must be solved as part of this plan

Gotcha 1 — service.toml [[env]] PATH_ROOT block per Lesson #19

Every daemon needs [[env]] name="PATH_ROOT" default="~/hero" block in its repo's service.toml, otherwise hero_proc-spawned actions panic at paths.rs:38:32. Status (2026-05-19):

  • mycelium_network — fixed in PR #48 (4 daemons)
  • All other 19 demo-set repos — status unknown, must audit

Phase 1 step 6 (auto-registration from --info --json) must inject PATH_ROOT into every action's env block as a safety net. Alternatively: audit and fix every repo's service.toml before this plan starts. Recommend belt-and-suspenders.

Gotcha 2 — old CLI flags vs new CLI flags

Several services changed CLI between the May-1 deploy and today's latest:

  • hero_router: --port 0 --address 10.1.2.2 --ui-port 9990 → --bind <ADDR:PORT> (repeatable)
  • Others likely similar; audit via --help on each new binary before writing the registration script.

The auto-registration must derive the start command from service.toml [[binaries]] + [[binaries.sockets]] + [[binaries.tcp]] blocks (which are the new source of truth), NOT from old action scripts.

Gotcha 3 — lab build --download --install doesn't strip the platform suffix for non-host platforms

lab build --download --install --platforms linux-musl-x86_64 on a glibc-x86_64 host downloads <bin>-linux-musl-x86_64 to ~/hero/build/bins/ but does NOT copy to ~/hero/bin/<bin> because lab considers linux-musl-x86_64 ≠ host. The musl-static binaries DO run on glibc Linux; this is an over-conservative gate.

Workaround in the bootstrap script:

for src in ~/hero/build/bins/*-linux-musl-x86_64; do
  dst=$(basename "$src" -linux-musl-x86_64)
  cp -f "$src" ~/hero/bin/"$dst"
  chmod +x ~/hero/bin/"$dst"
done

Upstream fix would be either:
(a) lab build --install treats musl-static as host-compatible on glibc Linux (sensible default), OR
(b) Add --install-musl-as-host opt-in flag.

Worth filing as a separate lab issue. For now, the bootstrap script handles it inline.

Gotcha 4 — install.sh 404 at the canonical URL (also blocks hero_skills#268)

The lab skill advertises https://forge.ourworld.tf/lhumina_code/hero_skills/raw/branch/development/crates/lab/install.sh but that URL returns 404. The bootstrap script currently needs scp of the local lab binary as a workaround. Tracked in hero_skills#268; resolution unblocks both this issue and that one.

Definition of done

  • hero_skills#268 gotchas 1 (install.sh) and 2 (reusable workflows) closed enough to call lab in CI
  • All 20 demo-set repo service.toml files audited; missing [[env]] PATH_ROOT blocks added (or auto-injection landed in bootstrap)
  • bootstrap_droplet_releases.sh lands in hero_demo/deploy/cloud_vm/scripts/ and replaces _source in the canonical flow
  • DO droplet provisioned via do_droplet_create.sh + bootstrap script
  • All 22 services running with v0.6.0 hero_proc_server
  • Browser smoke test passes on the new FQDN
  • DNS (Cloudflare) updated; HTTPS basic-auth gate intact
  • hero.gent04.grid.tf cancelled only after 24h green window on the new deploy
  • CLAUDE.md "herodemo VM" table updated with the new FQDN/IP
  • memory/project_demo_service_set.md reviewed against actual deploy

Estimated effort

  • Phase 1 (bootstrap script rework + service-registration generator): 3–5 hours
  • Phase 2 (provision + initial deploy): 1 hour
  • Phase 3 (verification + iteration on any registration failures): 1–3 hours
  • Total: 5–9 hours, one focused session each for phases 1 and 2–3

What's already done (skip these — don't re-do)

  • All 20 demo-set repos have musl-x86_64 binaries on Forgejo latest release (populated 2026-05-19; hero_proc, hero_router, hero_os, hero_osis, hero_db, hero_collab, hero_livekit, hero_aibroker, hero_embedder, hero_indexer, hero_biz, hero_slides, hero_books, hero_office, hero_proxy, hero_foundry, hero_logic, hero_code, hero_whiteboard + hero_proc)
  • TFGrid contracts for herodemo, herozero, heroci cancelled
  • Workstation cleanup: 250+ GB freed (build artifacts + cargo target dirs nuked; can be regenerated from Forgejo releases or cargo cache)

Related issues

  • hero_skills#268 — Auto-publish lab-latest binaries from CI on push-to-development
  • mycelium_network#46 — branch convention (default development_crate_layout for that repo)
  • hero_proc#86 META — reliability / supervisor-vs-socket drift (home#202)
  • hero_proc#105 — per-repo lab build/infocheck flow
## Summary Provision a fresh herodemo on a **DigitalOcean droplet** using the canonical **lab build/install** flow (download prebuilt musl-x86_64 binaries from each repo's `latest` Forgejo release — no source compile on the VM). Replace the dead TFGrid herodemo at `herodemo.gent01.grid.tf` (contracts cancelled 2026-05-19, see below). Keep the older `hero.gent04.grid.tf` deployment untouched as the fallback during transition. ## Why now The 2026-01-16-vintage TFGrid herodemo VM accumulated 2–3 weeks of binary drift (most services on May 1 / May 6 builds) and hit the home#202 supervisor-vs-socket drift pattern multiple times in one inspection. A 2026-05-19 attempt to upgrade in-place to `hero_proc_server v0.6.0` exposed: 1. New v0.6.0 daemon's spec_json format is incompatible with the v0.4.4 service registry (schema identical, content not). Old DB rows are wiped on first start. 2. Old action scripts hardcode old CLI flags (e.g., `hero_router --port 9988`); new binaries reject those (now `--bind <ADDR:PORT>`). 3. Many service.toml `[[env]]` blocks lack `PATH_ROOT` — daemons panic at `paths.rs:38:32` per Lesson #19 / s125 (`mycelium_network` PR #48 added this exact fix to 4 daemons). 4. No source-of-truth registration script exists on either VM or workstation. `nutools/modules/services/` in hero_skills HEAD has been gutted to a single file; `bootstrap_droplet_source.sh` clones source but does not register services. Net: upgrading in-place is more risky than a fresh provision. The fresh provision uses today's `latest` Forgejo releases — which we just populated for the full canonical demo set (~20 repos). ## Cancelled / contract state Cancelled on 2026-05-19 via `tfcmd cancel contracts`: - `herodemo` (5 contracts): net 2091015 + 2091016, vm 2091017, gateway 2091019, name 2091018 → `herodemo.gent01.grid.tf` is GONE - `herozero` (2 contracts) + `heroci` (5 contracts) — earlier in the same session Kept on TFGrid: - `hero` (4 contracts: net 2070724, vm 2070725, gateway 2070727, name 2070726) → `hero.gent04.grid.tf` — **DO NOT CANCEL** until DO droplet is green. This is the only Hero deploy left during the transition window. ## New target architecture | Layer | Old (cancelled) | New | |---|---|---| | Infra | TFGrid VM via `tfgrid-compose` | **DigitalOcean droplet** (existing `do_droplet_create.sh` + `cf_dns_set.sh`) | | Binaries | Source-built on VM via `hero_builder` | **Forgejo `latest` release downloads** via `lab build <repo> --download --install` | | Supervisor | hero_proc_server v0.4.4 | hero_proc_server v0.6.0 (current `latest`) | | Service registration | Manual after bootstrap | **Canonical bootstrap script** that registers each service from its `--info --json` output | | Auth gate | nginx basic-auth | nginx basic-auth (unchanged) | | Domain | `herodemo.gent01.grid.tf` (TFGrid name contract) | `<name>.gent01.grid.tf` or DO-managed FQDN; Cloudflare/etc. proxying as needed | ## Plan ### Phase 1 — bootstrap script rework Update `deploy/cloud_vm/scripts/bootstrap_droplet_source.sh` (or write a new `bootstrap_droplet_releases.sh`) to: 1. Install base packages (existing logic) 2. Install `lab` (one-line install — depends on hero_skills#268 install.sh fix) 3. Run `lab user init --root ~/hero` to populate `init.sh` with `PATH_ROOT`/`PATH_VAR`/`PATH_BUILD`/`PATH_CODE`/`HERO_SOCKET_DIR` 4. For each repo in the canonical demo set: `lab build <repo> --download --install --platforms linux-musl-x86_64` — pulls today's `latest` binaries to `~/hero/build/bins/`, then copies them with platform-suffix-stripped names to `~/hero/bin/` 5. Start `hero_proc_server` in screen with the full env exported 6. Register all 22 services via a generated script that walks each `~/hero/bin/<bin>` and calls `--info --json`, then uses `hero_proc service add` + `hero_proc service add-job` with proper script/env/health-check/restart-policy 7. Start all services in dependency order 8. Drop nginx + basic-auth config (unchanged from current herodemo) 9. Configure DNS (Cloudflare via `cf_dns_set.sh`) ### Phase 2 — DO droplet provisioning - Size: 16 CPU / 32 GB RAM / 200 GB disk (matches old herodemo specs) - Region: nearest to user base - Use existing `deploy/cloud_vm/scripts/do_droplet_create.sh` for create - One-shot bootstrap: `scp` then `ssh ... bash bootstrap_droplet_releases.sh` ### Phase 3 — verification - Browser smoke test: `https://<new-fqdn>/hero_os/ui` loads past the WASM shell - All 22 services healthy per `hero_proc service list` - All per-domain `hero_osis_*` sockets respond 200 to `/health` - `hero_router` log shows N services scanned, ≥95% healthy - Cancel `hero.gent04.grid.tf` only AFTER new deploy is green for 24h+ ### Phase 4 — clean-up - Strip the `bootstrap_droplet_source.sh` clone-and-source-build path (kept as `_source` variant in the script archive) once `_releases` is proven - Update CLAUDE.md "herodemo VM" table with the new FQDN/IP - Update `memory/project_demo_service_set.md` if the canonical set drifts ## Gotchas — must be solved as part of this plan ### Gotcha 1 — service.toml `[[env]] PATH_ROOT` block per Lesson #19 Every daemon needs `[[env]] name="PATH_ROOT" default="~/hero"` block in its repo's `service.toml`, otherwise hero_proc-spawned actions panic at `paths.rs:38:32`. Status (2026-05-19): - `mycelium_network` — fixed in PR #48 (4 daemons) - All other 19 demo-set repos — **status unknown, must audit** Phase 1 step 6 (auto-registration from `--info --json`) must inject `PATH_ROOT` into every action's env block as a safety net. Alternatively: audit and fix every repo's `service.toml` before this plan starts. Recommend belt-and-suspenders. ### Gotcha 2 — old CLI flags vs new CLI flags Several services changed CLI between the May-1 deploy and today's `latest`: - `hero_router`: `--port 0 --address 10.1.2.2 --ui-port 9990` → `--bind <ADDR:PORT>` (repeatable) - Others likely similar; audit via `--help` on each new binary before writing the registration script. The auto-registration must derive the start command from `service.toml` `[[binaries]]` + `[[binaries.sockets]]` + `[[binaries.tcp]]` blocks (which are the new source of truth), NOT from old action scripts. ### Gotcha 3 — `lab build --download --install` doesn't strip the platform suffix for non-host platforms `lab build --download --install --platforms linux-musl-x86_64` on a glibc-x86_64 host downloads `<bin>-linux-musl-x86_64` to `~/hero/build/bins/` but does **NOT** copy to `~/hero/bin/<bin>` because lab considers `linux-musl-x86_64` ≠ `host`. The musl-static binaries DO run on glibc Linux; this is an over-conservative gate. Workaround in the bootstrap script: ```bash for src in ~/hero/build/bins/*-linux-musl-x86_64; do dst=$(basename "$src" -linux-musl-x86_64) cp -f "$src" ~/hero/bin/"$dst" chmod +x ~/hero/bin/"$dst" done ``` Upstream fix would be either: (a) `lab build --install` treats musl-static as host-compatible on glibc Linux (sensible default), OR (b) Add `--install-musl-as-host` opt-in flag. Worth filing as a separate `lab` issue. For now, the bootstrap script handles it inline. ### Gotcha 4 — `install.sh` 404 at the canonical URL (also blocks hero_skills#268) The lab skill advertises `https://forge.ourworld.tf/lhumina_code/hero_skills/raw/branch/development/crates/lab/install.sh` but that URL returns 404. The bootstrap script currently needs `scp` of the local `lab` binary as a workaround. Tracked in hero_skills#268; resolution unblocks both this issue and that one. ## Definition of done - [ ] hero_skills#268 gotchas 1 (install.sh) and 2 (reusable workflows) closed enough to call `lab` in CI - [ ] All 20 demo-set repo `service.toml` files audited; missing `[[env]] PATH_ROOT` blocks added (or auto-injection landed in bootstrap) - [ ] `bootstrap_droplet_releases.sh` lands in `hero_demo/deploy/cloud_vm/scripts/` and replaces `_source` in the canonical flow - [ ] DO droplet provisioned via `do_droplet_create.sh` + bootstrap script - [ ] All 22 services running with v0.6.0 hero_proc_server - [ ] Browser smoke test passes on the new FQDN - [ ] DNS (Cloudflare) updated; HTTPS basic-auth gate intact - [ ] `hero.gent04.grid.tf` cancelled only after 24h green window on the new deploy - [ ] CLAUDE.md "herodemo VM" table updated with the new FQDN/IP - [ ] `memory/project_demo_service_set.md` reviewed against actual deploy ## Estimated effort - Phase 1 (bootstrap script rework + service-registration generator): **3–5 hours** - Phase 2 (provision + initial deploy): **1 hour** - Phase 3 (verification + iteration on any registration failures): **1–3 hours** - Total: **5–9 hours**, one focused session each for phases 1 and 2–3 ## What's already done (skip these — don't re-do) - All 20 demo-set repos have musl-x86_64 binaries on Forgejo `latest` release (populated 2026-05-19; `hero_proc`, `hero_router`, `hero_os`, `hero_osis`, `hero_db`, `hero_collab`, `hero_livekit`, `hero_aibroker`, `hero_embedder`, `hero_indexer`, `hero_biz`, `hero_slides`, `hero_books`, `hero_office`, `hero_proxy`, `hero_foundry`, `hero_logic`, `hero_code`, `hero_whiteboard` + `hero_proc`) - TFGrid contracts for `herodemo`, `herozero`, `heroci` cancelled - Workstation cleanup: 250+ GB freed (build artifacts + cargo target dirs nuked; can be regenerated from Forgejo releases or cargo cache) ## Related issues - hero_skills#268 — Auto-publish lab-latest binaries from CI on push-to-development - mycelium_network#46 — branch convention (default `development_crate_layout` for that repo) - hero_proc#86 META — reliability / supervisor-vs-socket drift (home#202) - hero_proc#105 — per-repo lab build/infocheck flow
mik-tf commented 2026-05-20 21:54:04 +00:00
Author
Owner
Copy link

s132 close — TFGrid VM bootstrap from binaries proven end-to-end

The original arc this issue tracks (s132 = TFGrid VM bootstrap → s133 = app services → s134 = gateway + verification) has been rescoped post-meeting. Today's s132 work delivered the first leg + then the whole arc realigned to the new hero_os_tfgrid_deployer / hero_cockpit umbrella per the meeting minutes shared in hero_os_tfgrid_deployer#1.

What s132 landed

  • VM: TFGrid node 8 (gent02), 16 CPU / 8 GB / 200 GB / 16 GB rootfs / mycelium-only, provisioned via make deploy ENV=herolab (OpenTofu) in 61 s. Mycelium IPv6 4fe:c68d:e525:af6a:ff0f:d77d:6b71:f322. Gateway herolab.gent02.grid.tf.
  • Bootstrap: make setup-binaries ENV=herolab → apt → driver user → curl prebuilt lab from hero_skills latest → 34/34 PASS on lab build $repo --download --install (mycelium_network skipped — TFGrid native via zinit) → 3 libonnxruntime sonames installed → hero_proc_server PID 6971 + hero_router PID 7070 via lab service → 6/6 smoke tests pass → curl http://127.0.0.1:9988/.well-known/heroservice.json → HTTP 200.
  • Commit: 09f8365 — 11 dev_mik commits squashed direct-to-development; +252/-1271 across 26 files (deleted 8 legacy env profiles + deploy/cloud_vm/; added envs/herolab/ + scripts/setup-binaries.sh + scripts/d07_set.txt + Makefile setup-binaries target).

What this issue's s133-s134 plan becomes

The original plan was "start all 34 app services" (s133) → "nginx + LE + htpasswd + Cloudflare" (s134). Per the meeting, this scope is now absorbed into the larger demo-deployer arc:

  • The "start all 24 services" piece becomes per-user component selection driven by hero_cockpit on each VM (deferred to Track A in the new roadmap).
  • The "nginx + LE + htpasswd + Cloudflare" piece becomes hero_proxy + Forge OAuth + TFGrid name_proxy (Track B in the new roadmap).
  • The umbrella moves from this issue to hero_os_tfgrid_deployer#1.

Known followup carried forward

  • Gateway HTTP 502 at https://herolab.gent02.grid.tf: hero_router binds to loopback by default; needs --bind 0.0.0.0 (s74 work) + hero_proxy in front. Tracked as Track B (s140 territory) in the new roadmap.

Closing recommendation

This issue can be closed once the team confirms the rescope. The substantive s132 piece (VM bootstrap from binaries) is GREEN; the rest is rerouted to the new arc.

Full session narrative + per-commit detail in sessions/132.yml (local workspace).

## s132 close — TFGrid VM bootstrap from binaries proven end-to-end The original arc this issue tracks (s132 = TFGrid VM bootstrap → s133 = app services → s134 = gateway + verification) has been **rescoped post-meeting**. Today's s132 work delivered the first leg + then the whole arc realigned to the new hero_os_tfgrid_deployer / hero_cockpit umbrella per the meeting minutes shared in [hero_os_tfgrid_deployer#1](https://forge.ourworld.tf/lhumina_code/hero_os_tfgrid_deployer/issues/1). ### What s132 landed - **VM**: TFGrid node 8 (gent02), 16 CPU / 8 GB / 200 GB / 16 GB rootfs / mycelium-only, provisioned via `make deploy ENV=herolab` (OpenTofu) in 61 s. Mycelium IPv6 `4fe:c68d:e525:af6a:ff0f:d77d:6b71:f322`. Gateway `herolab.gent02.grid.tf`. - **Bootstrap**: `make setup-binaries ENV=herolab` → apt → driver user → curl prebuilt lab from hero_skills latest → 34/34 PASS on `lab build $repo --download --install` (mycelium_network skipped — TFGrid native via zinit) → 3 libonnxruntime sonames installed → hero_proc_server PID 6971 + hero_router PID 7070 via `lab service` → 6/6 smoke tests pass → `curl http://127.0.0.1:9988/.well-known/heroservice.json` → HTTP 200. - **Commit**: [`09f8365`](https://forge.ourworld.tf/lhumina_code/hero_demo/commit/09f8365) — 11 dev_mik commits squashed direct-to-development; +252/-1271 across 26 files (deleted 8 legacy env profiles + deploy/cloud_vm/; added envs/herolab/ + scripts/setup-binaries.sh + scripts/d07_set.txt + Makefile setup-binaries target). ### What this issue's s133-s134 plan becomes The original plan was "start all 34 app services" (s133) → "nginx + LE + htpasswd + Cloudflare" (s134). Per the meeting, this scope is now absorbed into the larger demo-deployer arc: - The "start all 24 services" piece becomes **per-user component selection** driven by hero_cockpit on each VM (deferred to Track A in the new roadmap). - The "nginx + LE + htpasswd + Cloudflare" piece becomes **hero_proxy + Forge OAuth + TFGrid name_proxy** (Track B in the new roadmap). - The umbrella moves from this issue to [hero_os_tfgrid_deployer#1](https://forge.ourworld.tf/lhumina_code/hero_os_tfgrid_deployer/issues/1). ### Known followup carried forward - **Gateway HTTP 502** at `https://herolab.gent02.grid.tf`: hero_router binds to loopback by default; needs `--bind 0.0.0.0` (s74 work) + hero_proxy in front. Tracked as Track B (s140 territory) in the new roadmap. ### Closing recommendation This issue can be closed once the team confirms the rescope. The substantive s132 piece (VM bootstrap from binaries) is GREEN; the rest is rerouted to the new arc. Full session narrative + per-commit detail in [`sessions/132.yml`](https://forge.ourworld.tf/lhumina_code/hero_demo) (local workspace).
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
development
v0.9.3-dev
v0.9.0-dev
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/hero_demo#66
No description provided.