oikos/oikos/console/deploy/README.md

Oikos Console — deploy notes

Deploys the same way homelab-mcp and secrets-issuance already do: Shape B webhook (own checkout, own systemd units, own deploy secret) on LXC 105 (apps), reading HOMELAB_CONTEXT_DIR=/opt/homelab-context for all data. See infrastructure/auto-deploy.md for the general pattern; webhook ids 10 (homelab-mcp, :9811) and 11 (secrets-issuance, :9821) are the direct precedent — this is a third webhook on dtoro/Homelab-Docs, port :9831.

Status (2026-07-06)

• Gitea webhook: done. Registered via the Gitea API as webhook id 14 (http://192.168.8.205:9831/deploy, push events, main branch filter, active). See infrastructure/auto-deploy.md.
• Console deploy on apps (105): not yet done. Direct SSH bootstrap was withheld pending explicit operator execution — see "One-time setup" below. Important: webhook 14's secret was generated and registered with Gitea before the apps-side install (order reversed from the usual flow). It's encrypted at secrets/oikos-console-deploy-secret.yaml (recipient: apps only). When you run webhook/install.sh below, skip its random-secret generation — instead run homelab secret oikos-console-deploy-secret on apps and write the webhook_secret value into /etc/oikos-console-deploy/secret yourself.
• Caddy route: not yet done.
• DNS entry: not yet done.

One-time setup on apps (105)

git clone https://git.hubris.network/dtoro/Homelab-Docs.git /opt/oikos-console
cd /opt/oikos-console
./oikos/console/deploy/deploy.sh                 # first install
./oikos/console/deploy/webhook/install.sh        # generates a NEW secret by default —
                                                  # see "Status" above before running this
systemctl enable --now oikos-console.service oikos-console-deploy.service

Caddy route — NOT in this repo, needs manual addition to dtoro/caddy-conf

The console binds 127.0.0.1:8091 on apps only (see oikos-console.service — ProtectSystem=strict, no LAN listener); Caddy on LXC 121 reaches it via apps' LAN IP, not loopback (they're different hosts). Site block, forward-auth gated the same way other LAN-only services are (confirmed syntax per containers/121-caddy.md: import authentik, no parens in the import statement itself — the snippet is defined as (authentik) but imported as authentik):

oikos.hubris.network {
    import authentik
    reverse_proxy 192.168.8.205:8091
}

Add oikos.hubris.network to the split-horizon DNS zone (Technitium, LXC 107) pointing at Caddy's LAN IP, same as every other *.hubris.network host.

Authentik step-up re-auth on approval actions — deferred, needs live Authentik

The Week-4 plan calls for the /approvals/{id}/reply POST specifically to require fresh re-authentication (not just an existing session), so a stolen session cookie can't approve a mutation. That's an Authentik policy binding (a PromptStage/reauth flow scoped to that path), which needs a live Authentik instance to configure and test — not buildable or verifiable from a repo checkout alone. Today the whole console (including this route) is protected the same way every other console-with-a-forward- auth-gate service is: the ingress-level Authentik check, not a per-action step-up. Tracked in the 60/90-day backlog (OIKOS.md).

What this deploy does NOT do

• Does not run any homelab command directly. Approving in the console issues a grant token exactly like approving via Matrix would — actually executing the gated action still goes through the homelab CLI on whichever host runs it, with --approval-id.
• Does not touch inventory.yaml, secrets/, or anything outside signals/ and approvals/ (both committed+pushed immediately on write, see oikos/console/app.py's _commit_push()).