Add web-based architecture plan with Supabase, Railway, and Cloudflare Pages (multi-user MCP support)

[Copilot]

Complete Phase 1: infrastructure planning and configuration for web-based TinyBrain deployment with multi-user MCP server architecture.

Architecture

Distributed cloud stack replacing local PocketBase:

• Supabase: PostgreSQL + auth + realtime (replaces SQLite)
• Railway: Go backend API + MCP adapter (replaces local server)
• Cloudflare Pages: Frontend + edge workers (new)

Users → CF Pages (CDN/Workers) → Railway (Go API + MCP) → Supabase (PostgreSQL+Auth)

Multi-User MCP Architecture (New)

Two-Domain Design:

• app.tinybrain.io: Web dashboard for human users
• mcp.tinybrain.io: MCP protocol endpoint for AI assistants (Claude, Cursor)

Dual Authentication System:

• Web users: JWT tokens (Supabase Auth)
• MCP clients: API keys (generated in web app, 32+ bytes → base64-encoded)

Data Isolation: Row Level Security (RLS) ensures each user only sees their own data (plus team-shared data)

Single Backend, Dual Interfaces:

Railway Backend
├── /api/*     → REST API (for web app)
└── /v1/mcp    → MCP endpoint (for AI assistants)
      ↓
Both interfaces share:
- Same business logic
- Same Supabase database
- User context from JWT/API key → RLS filtering

Cloudflare Workers Proxy for MCP endpoint:

• Edge rate limiting (1000 req/hour per API key)
• DDoS protection
• API key validation at edge

Database Schema (supabase/migrations/)

• 001_initial_schema.sql: 14 tables (users, teams, sessions, memories, relationships, security data, api_keys)
• 002_row_level_security.sql: RLS policies for user/team isolation

Key changes:

• Multi-tenancy via team_id and RLS policies
• Security knowledge hub tables (NVD, MITRE ATT&CK, OWASP, CWE)
• Full-text search indexes on memories
• API keys table for MCP authentication
• Helper functions: is_team_member(), get_related_memories()

Infrastructure Configs

Railway (railway.toml, railway/Dockerfile):

[build]
buildCommand = "go build -o server ./cmd/tinybrain"
[deploy]
startCommand = "./server serve"
healthcheckPath = "/health"

Cloudflare (cloudflare/workers/api-proxy.ts):

• Edge caching with configurable TTLs
• Rate limiting (100 req/min per IP)
• Security headers (CSP, HSTS, etc.)
• MCP proxy worker with API key validation

CI/CD (.github/workflows/deploy-web.yml):

• Automated Railway deployments on push
• CodeQL with explicit job permissions
• Integration tests post-deploy

Documentation

• WEB_ARCHITECTURE.md: Component responsibilities, data flows, security model
• DEPLOYMENT_GUIDE.md: Supabase/Railway/Cloudflare setup procedures
• PHASE2_BACKEND_QUICKSTART.md: Supabase client integration examples
• IMPLEMENTATION_PLAN.md: 7-phase roadmap (4-6 months, $60-80/mo)
• MULTI_USER_MCP_ARCHITECTURE.md: Complete multi-user MCP design with API key auth (NEW)
• diagrams/DUAL_ENDPOINT_ARCHITECTURE.md: Visual architecture diagrams and data flows (NEW)

Environment Template (.env.example)

SUPABASE_URL=https://xxx.supabase.co
SUPABASE_SERVICE_KEY=...
DATABASE_URL=postgresql://...
JWT_SECRET=...
CORS_ALLOWED_ORIGINS=...

Cost Estimate

Production: $60-80/month (Supabase Pro $25 + Railway $30-50 + Cloudflare Workers $5)
Prices as of December 2024

Next Phase

Phase 2 implements:

• REST/GraphQL endpoints with Supabase Go client
• Multi-user MCP endpoint with API key authentication
• API key management system
• Maintaining MCP backward compatibility

Original prompt

Help me construct a plan to implement a web-based version of tinybrain that uses Supabase and Railway.app and Cloudflare pages for any static site/dynamic content where possible

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[rainmana]

@copilot I'm not sure what the best way to do this would be, but how do we make sure that more than one user can use the web-based MCP server (multi-user) and how do we also create a single endpoint for people to use too? Not sure if that makes sense? It seems like there should be a web app/static site, and then a totally seperate host name for the MCP target, and both are backed by Supabase so that data can be utilitzed in both the web app and the MCP server (both backed by Supabase) but the MCP server fronted by maybe some kind of proxy or something? I'm not super sure??

[Copilot]

@copilot I'm not sure what the best way to do this would be, but how do we make sure that more than one user can use the web-based MCP server (multi-user) and how do we also create a single endpoint f...

Great question! I've added comprehensive documentation to clarify the multi-user MCP architecture.

Two-Domain Architecture (commit 8d8c26e):

1. app.tinybrain.io - Web dashboard

   • Human users access via browser
   • JWT authentication (Supabase Auth)
   • Manage memories, sessions, teams
   • Generate and manage API keys

2. mcp.tinybrain.io - MCP protocol endpoint

   • AI assistants (Claude, Cursor) connect here
   • API key authentication (generated in web app)
   • Same data as web app via shared Supabase backend
   • Cloudflare Workers proxy for rate limiting & DDoS protection

How Multi-User Works:

• Web users: Sign in → get JWT → make API calls → RLS filters by user_id
• MCP clients: Use API key → Railway validates → looks up user_id → RLS filters by user_id
• Data isolation: Row Level Security (RLS) policies ensure each user only sees their own data (+ team shared data)

Single Backend, Dual Interfaces:

Railway Backend
├── /api/*     → REST API (for web app)
└── /v1/mcp    → MCP endpoint (for AI assistants)
      ↓
Both use same business logic & Supabase database

Key docs added:

• MULTI_USER_MCP_ARCHITECTURE.md - Complete multi-user design
• diagrams/DUAL_ENDPOINT_ARCHITECTURE.md - Visual flow diagrams

The architecture enables both web and programmatic access to the same multi-user TinyBrain instance with proper authentication and data isolation.