research: Railway as a hosting channel — container platform vs the docker-socket requirement

[vybe]

Summary

Railway has popular one-click templates (e.g. n8n) and strong distribution, but it appears to deploy managed containers rather than VMs. Trinity needs to control which containers it runs (Docker socket / compose lifecycle), which likely rules Railway out for the one-click hosted install. Verify this properly instead of assuming.

Context

Raised during release planning (2026-08-21): Railway was deliberately left out of the first hosting wave (#2281–#2283 target VM-based providers, per #2280's prebuilt-image approach). Low pressure — "if we can make it work in a relatively painless manner it would be great, but happy to be wrong."

Acceptance Criteria

• Determine whether Railway can run Trinity's multi-container architecture with the platform controlling container lifecycle (a docker-socket equivalent or a Railway-native alternative)
• If feasible: outline what a Railway template would need and file the follow-up listing issue
• If not feasible: record here exactly what blocks it and close — the finding is the deliverable

[obasilakis]

The concrete test, so this stays half a day (survey, 2026-09-11)

Nothing blocks this research — the prebuilt images are public on GHCR and docker-compose.hosted.yml is on dev (#2280). The deliverable is the finding, so the useful thing is to name exactly what Railway has to support before anyone starts reading marketing pages:

1. A readable Docker socket. docker_service.py is the single point of Docker interaction and container state comes from Docker labels, not an in-memory registry (architecture invariant fix: Add process documentation volume mounts for production #11). The backend needs /var/run/docker.sock (read-only is enough) or a documented equivalent.
2. Creating sibling containers the platform did not declare. Agents are containers Trinity creates at runtime — a platform that only runs containers listed in a config file cannot host Trinity regardless of socket access.
3. Two user-defined bridge networks. trinity-agent-network (172.28.0.0/16) and trinity-platform-network (172.29.0.0/16), with agents deliberately unable to route to Redis. If Railway gives one flat network, that isolation property is lost and the answer is no even if 1 and 2 pass.
4. A persistent bind-mounted path for ~/trinity-data (SQLite, agent files, backups).

Requirement 2 is the one that most likely settles it, and it is the cheapest to check. If it fails, record which of the four failed and close — per the AC, that finding is the deliverable.