Story: Offload service and DB runtime to a WSL host over SSH
Table of Contents
This page documents a story in Product backlog — inbox, carried unfinished from Sprint 24 at close. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
Goal
Split from Containerize the ORE Studio service runtime and verify it on a remote WSL host at sprint 24 close: the actual cutover to running the dev environment's services/DB on a WSL host day-to-day, starting with first-class compass tooling to build/stage/transfer/ deploy the service-runtime image to a remote host, replacing the current manual SSH/podman sequence.
Distinct from Systemd resource management and per-environment
isolation's WS-3 (compass systemd deploy): that workstream installs
generated ores@<env>.target units into the local machine's
~/.config/systemd/user/; this story is about building, staging, and
transferring a service-runtime image to a remote host over SSH.
Same word ("deploy"), different problem.
Status
| Field | Value |
|---|---|
| State | DONE |
| Carried from | Sprint 24 (unfinished at close) |
| Now | Superseded by Remote WSL offload and compute nodes — task moved to sprint 25. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-08-10 |
Acceptance
- Compass has first-class tooling (e.g. compass env deploy) to build, stage, transfer, and deploy the service-runtime image to a remote host, replacing the manual SSH/podman sequence; the dev workflow is actually cut over to using a WSL host day-to-day, with documented, repeatable steps for standing the environment up and tearing it down.
Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
Decisions
- WSL boxes are multi-role hosts, not single-purpose runtime hosts.
Product-owner constraint: the WSL boxes must also run compute nodes
(
ores.compute.wrapper) for other environments. Deploy tooling is role-based — full service/DB runtime host, or compute-node-only (wrapper + certs, connecting outward to the serving environment's NATS core with its--host-id; NATS/TLS only, no DB access). - Remote containers run with =–network=host, not in a pod. Postgres
is a native install on the WSL host (localhost:5433), unreachable
through a pod's slirp4netns; services run with
--user <uid>:<gid>and--userns=keep-id, and service config arrives as env (ORES_<APP>_<OPTION>via the C++ environment mapper), not per-service CLI args — the containers pass no service-specific flags. - Writable runtime dirs are host bind-mounts, not in-image dirs. The
chainguard glibc base has no shell (no
RUN), and buildah normalizesCOPYdirectory modes to 0755 root-owned, so log, storage, and the ore.service work dir are host-owned dirs bind-mounted over their /app placeholders byremote-run.sh.