Skip to content

Staging CVM roles + what depends on them (webhost-staging vs hermes-staging) #59

Description

@amiller

Two dev-OS / pha / prod7 CVMs look redundant but are different layers — documenting so it's clear what depends on which.

webhost-staging = daemon-IMAGE test box (RFC 0023)

Where the Paseo loop rebuilds & tests the tee-daemon itself. Depends on it: #57 (RFC 0017 export/import) and #58 (RFC 0026 scoped debug) — both are daemon code, so they build/verify here. You cannot do daemon-image dev on hermes-staging: rebuilding the daemon restarts it and would take down its ~17 live apps. So webhost-staging is not retire-able.

hermes-staging = the app host (misnamed — not really 'staging')

Runs the ~17 non-promoted apps (otterscope, listen, router-dashboard, vault, tinycloud, …). App-level dev can happen here; daemon-image dev cannot.

Ship flow (RFC 0023)

Paseo loop → staging-NN branch → PR (built/tested on webhost-staging). Prod is a laptop-only gated step: review + merge PR to origin/main, then ship-fix.sh prod (the prod target + TEE_DAEMON_TOKEN live only on the laptop).

Parked (mechanics, not principle)

Bulk-migrating the ~17 apps onto the prod base CVM (oauth3-prod7 / pod.dstack) is deferred, not rejected — pod.dstack is a general daemon meant to host dev+attested apps (mode is per-project, #16). Needs: DAEMON_CONTAINER_RUNTIME=runc (enabler — prod-OS has no runsc), a resize, source-pulls (7 apps' sources are only on the hermes-staging daemon disk), per-project secrets.

Tidy-up

Retire-able: legacy Gen-1 enclave oauth3-proxy-staging (prod9), duplicate shared-key-demo-2. Longer-term: rename hermes-staging.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions