Wild deploy: separated frontend + backend on node_hub #21

New issue

Closed

opened 2026-06-26 15:22:23 +00:00 by Mark · 2 comments

Mark commented

2026-06-26 15:22:23 +00:00

Owner

Context

The actors-test stack (#20) bundles frontend + backend for end-to-end testing on the tailnet. The production / "wild" deploy keeps them separated: the frontend ships as a static bundle on a web surface, the backend keeps its current single-container node_hub app. This issue is the wild topology.

Goal

Two node_hub-managed apps, two URLs, two lifecycles:

easystitch-service — unchanged from its current single-container deploy (see Mark/easystitch-service/docs/deployment.md). Already live on the tailnet; this issue is about versioning + the handoff, not new code.
threadcraft-web — ThreadCraft's vite build output served as static files. New node_hub app.

Acceptance

threadcraft-web registered as a node_hub app, separate from the backend.
Frontend's VITE_API_BASE (or equivalent) pointed at the wild backend's tailnet URL.
Backend's ALLOWED_ORIGINS env var includes the wild frontend's origin.
Independent deploys: bumping the frontend does not redeploy the backend and vice versa.
Wild backend is the same image used by the actors-test stack (#20) so behaviour doesn't diverge.

Mark/Kimi_Agent_Brother_10_Digitizing_App#20 — Actors stack (single-compose for testing).
Mark/easystitch-service deployment doc — backend image source of truth.

Out of scope

The actors-test deploy (#20).
Multi-region / failover / CDN (single tailnet deploy is enough for v1).

## Context The actors-test stack (#20) bundles frontend + backend for end-to-end testing on the tailnet. The **production / "wild"** deploy keeps them separated: the frontend ships as a static bundle on a web surface, the backend keeps its current single-container node_hub app. This issue is the wild topology. ## Goal Two node_hub-managed apps, two URLs, two lifecycles: 1. **easystitch-service** — unchanged from its current single-container deploy (see `Mark/easystitch-service/docs/deployment.md`). Already live on the tailnet; this issue is about **versioning + the handoff**, not new code. 2. **threadcraft-web** — ThreadCraft's `vite build` output served as static files. New node_hub app. ## Acceptance - [ ] `threadcraft-web` registered as a node_hub app, separate from the backend. - [ ] Frontend's `VITE_API_BASE` (or equivalent) pointed at the wild backend's tailnet URL. - [ ] Backend's `ALLOWED_ORIGINS` env var includes the wild frontend's origin. - [ ] Independent deploys: bumping the frontend does not redeploy the backend and vice versa. - [ ] Wild backend is the same image used by the actors-test stack (#20) so behaviour doesn't diverge. ## Related - Mark/Kimi_Agent_Brother_10_Digitizing_App#20 — Actors stack (single-compose for testing). - Mark/easystitch-service deployment doc — backend image source of truth. ## Out of scope - The actors-test deploy (#20). - Multi-region / failover / CDN (single tailnet deploy is enough for v1).

Mark added the

triage-approved

needs-decompose

labels

2026-06-26 15:22:33 +00:00

Mark commented

2026-06-26 15:22:34 +00:00

Author

Owner

Auto-triage: needs decompose

Marked triage-approved + needs-decompose. decompose-executor will pick this up and break it into implementable sub-issues.

## Auto-triage: needs decompose Marked `triage-approved` + `needs-decompose`. decompose-executor will pick this up and break it into implementable sub-issues.

Mark commented

2026-06-27 07:56:48 +00:00

Author

Owner

Auto-triage: needs decompose

Marked triage-approved + needs-decompose. decompose-executor will pick this up and break it into implementable sub-issues.

## Auto-triage: needs decompose Marked `triage-approved` + `needs-decompose`. decompose-executor will pick this up and break it into implementable sub-issues.

Mark

2026-06-27 07:56:51 +00:00