← back to Tools Dw Hub
add SCOPE-tools-public.md: tiered plan for publishing individual tools
7e42fdb294aabdea1b6c680f0b15da0ce44ca31b · 2026-07-28 11:16:34 -0700 · Steve
Files touched
Diff
commit 7e42fdb294aabdea1b6c680f0b15da0ce44ca31b
Author: Steve <steve@designerwallcoverings.com>
Date: Tue Jul 28 11:16:34 2026 -0700
add SCOPE-tools-public.md: tiered plan for publishing individual tools
---
SCOPE-tools-public.md | 63 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/SCOPE-tools-public.md b/SCOPE-tools-public.md
new file mode 100644
index 0000000..2d717a9
--- /dev/null
+++ b/SCOPE-tools-public.md
@@ -0,0 +1,63 @@
+# SCOPE — Make individual DW tools independently public (TK-10016)
+
+**Status:** scope only, nothing deployed. Each publish is a per-tool gated call for Steve.
+
+## The goal
+Today the hub (tools.designerwallcoverings.com) is public, but the tools it links to
+run on the Mac Studio (tailnet IP 100.82.17.107). Launch links only work from a
+tailnet-connected device. Making a tool "independently public" = deploy it to Kamatera
+so its own URL (e.g. `recolor.designerwallcoverings.com`) works from anywhere.
+
+## The crux — publish by WRITE-SURFACE, not blanket
+Grep of the tool sources shows they split into three risk tiers. **Do not blanket-deploy
+all 20.** A tool that mutates the live Shopify store is a bigger blast radius on a public
+URL than a client-side image utility.
+
+### Tier 1 — SAFE to publish (low effort, recommend yes)
+Pure utilities: no live-Shopify writes, no/È read-only data. Just need a pm2 process +
+basic-auth gate + subdomain (same recipe we just used for the hub).
+| Tool | Framework | Notes |
+|---|---|---|
+| Duplicate & Recolor v1.4 | node | No Shopify mutations, no DB dep. Cleanest candidate. |
+| Search by Color Wheel | static/next | No mutations, reads a color API. |
+| 150 DPI + Spoonflower flow | node | No Shopify mutations; **reads dw_unified** → point at Kamatera-local PG. |
+
+### Tier 2 — PUBLISH WITH CARE (medium effort, per-tool gate)
+Call paid APIs (Gemini) and may write metafields/tags. Publishable behind hard auth, but
+each needs: secrets on Kamatera (via /secrets fan-out), a cost guard, and confirm the
+write scope before exposing.
+- Kravet / Thibaut / Philippe Romano Taggers, DW Style Tag Updater
+- Image→Room Setting, Room Setting App (Gemini image gen = metered)
+
+### Tier 3 — KEEP TAILNET-ONLY (do NOT broadly publish)
+These **write to the production Shopify store** and/or drive bulk catalog mutations.
+Recommend they stay tailnet-only (reachable from the hub on your devices) or, if truly
+needed public, add an IP-allowlist on top of basic-auth.
+- **ImportNewSkufromURL** — hits `/admin/api/*/products` (creates/updates live products), needs DATABASE_URL + PG. (Also carries a `shpat_REDACTED` placeholder → must wire a real token via /secrets before it runs at all.)
+- Schumacher / Architectural / Maya Romanoff updaters, VendorDashboard-V2 — bulk vendor writes.
+- pm2-dashboard / system-dashboard — expose infra state; keep internal.
+
+## Shared deploy pattern (per tool, reused from the hub go-live)
+1. `/secrets` fan-out → put the tool's real env on Kamatera (never the hardcoded/redacted values).
+2. rsync tool → `/root/Projects/<tool>`; `pm2 start` on a fixed Kamatera-local port; `pm2 save`.
+3. Next.js tools need `npm run build` on Kamatera first (Tier 1/2 has 3 Next apps).
+4. DNS A record (proxied) `<tool>.designerwallcoverings.com` → 45.61.58.125 (**zone now 196/200 — ~4 slots; publishing many tools will hit the 200 cap → free retired records or move to a `/tool-path` reverse-proxy under the hub instead of N subdomains**).
+5. nginx IP-bound :443 vhost → `proxy_pass 127.0.0.1:<port>`; LE cert via **grey-cloud → webroot certonly → re-proxy** (the CF-proxy HTTP-01 workaround we already hit).
+6. Basic-auth gate on every tool (Tier 1 tools currently have NONE of their own) + open `/healthz`.
+
+## Effort estimate
+- Tier 1 (3 tools): ~30–45 min each. **Recommend doing these first as the proof.**
+- Tier 2 (6 tools): ~1 hr each (secrets + cost guard + build).
+- Tier 3: not recommended public; ~0 (leave as-is) unless Steve wants IP-allowlisted exposure.
+
+## Cap consideration
+20 tools × 1 subdomain each would blow the 200-record CF cap. Two paths:
+- **A (recommended):** reverse-proxy the safe tools UNDER the hub as paths
+ (`tools.designerwallcoverings.com/recolor`, `/colorwheel`, `/150dpi`) — **zero new DNS
+ records**, one cert, one auth gate. Needs each app to support a base-path (Next apps: `basePath`).
+- **B:** one subdomain per tool — simpler per app, but burns DNS slots fast.
+
+## Recommendation
+Start with **Tier 1 via Path-A reverse-proxy** (3 safe tools mounted under the existing
+hub, no new DNS, one auth gate). Prove it with **Duplicate & Recolor v1.4** first. Hold
+Tier 2 for a per-tool go, and keep Tier 3 tailnet-only.
← d1d5a15 wire TOOL_HOST/PROBE_HOST for public deploy (tailnet-reachab
·
back to Tools Dw Hub
·
fleet-revival hub correction (TK-10017): 26-tool manifest on 1cdc418 →