ADR-005: Deployment Strategy — UAT on Render, Production TBD

Status: ✅ Accepted (UAT) · 🔲 Pending (Production) Date: 2026-03-22 Decision Makers: Tilak Kumar

Context

ThreatWeaver needs to deploy a React SPA (frontend) and a Node.js API server (backend). The deployment platform affects cost, latency, developer experience, and operational complexity.

The key constraints:

Backend runs long-lived WebSocket connections for scan sensors (rules out serverless functions with 30s timeouts)
Backend requires persistent process memory (in-memory scan state, agent concurrency tracking)
Frontend is a pure static SPA — no server-side rendering needed
Database is PostgreSQL — hosted on Render (UAT) or to be decided for production
Budget: keep infrastructure costs minimal during development phase

Decision

UAT environment: Deploy everything to Render (backend + static site + PostgreSQL).

Production environment: Infrastructure not yet decided — will be finalized at launch using the main branch.

Active environments:

  Local (dev machines):
    Frontend  → localhost:3005 (npm run dev, native)
    Backend   → localhost:4005 (npm run dev, native)
    Database  → Docker PostgreSQL (port 5432)

  UAT (dev.threatweaver.ai):
    Frontend  → Render Static Site (dev.threatweaver.ai)
    Backend   → Render Pro Plus (threatweaver-backend.onrender.com)
    Database  → Render PostgreSQL Pro 8GB
    Branch    → dev (auto-deploys on push)

  Production (TBD):
    Frontend  → TBD at launch (Vercel / Cloudflare Pages / Render)
    Backend   → TBD at launch (Render / Railway / AWS)
    Database  → TBD at launch (Supabase / Render / Neon)
    Branch    → main (protected, manual release only)

Git branch → environment mapping:

Branch	Deploys to	Who triggers
`local`	Localhost only	Developer manually
`dev`	UAT (Render)	Auto on push
`main`	Production (TBD)	Manual release process

Consequences

Positive (UAT on Render):

Single platform (Render) for backend + frontend + database simplifies UAT management
No cross-platform coordination — one dashboard, one billing account
Render's persistent Node.js process supports WebSockets and long-running scans
UAT database is isolated from local dev — safe to test migrations against
Auto-deploy on dev push means UAT always reflects latest code

Negative / Trade-offs:

Render is Singapore region (ap-southeast-1) — slightly higher latency for US/EU users
No built-in horizontal scaling — manual instance scaling required
Render's PostgreSQL backup schedule is less flexible than Supabase
Production hosting decision is deferred — will require migration work when decided

What was removed:

kinavulnerabilitymanagement.vercel.app — old Vercel frontend URL, no longer active
kina-vulnerability-management-uq1t.onrender.com — old Render backend URL, no longer active
These URLs appeared in vercel.json, docusaurus.config.ts, and several docs — all cleaned up

Alternatives Considered

Option	Status
Vercel (frontend) + Render (backend) split	Used previously, removed. Re-evaluate at production launch.
Full Render (frontend + backend + DB)	Current UAT approach — working well
AWS (ECS + CloudFront)	Candidate for production — higher control, higher operational cost
Cloudflare Pages + Workers	Candidate for production — edge performance, but Workers have execution limits
Railway	Similar to Render, less mature — evaluate at launch
Self-hosted VPS	Too much operational overhead for small team

Production Decision Criteria (When Ready)

When production hosting is selected, evaluate against:

WebSocket support — scan sensors require long-lived connections
Persistent process — no cold starts, no serverless timeout limits
PostgreSQL managed service — daily backups, PITR, SSL enforced
Latency — target < 100ms p95 for API responses (Singapore → global)
Cost at scale — estimate for 50 concurrent tenants
Zero-downtime deploys — rolling restart or blue/green

Context​

Decision​

Git branch → environment mapping:​

Consequences​

Alternatives Considered​

Production Decision Criteria (When Ready)​