Architecture
This page covers how Control Seat is built for anyone who wants to understand what's running under the hood.
System Overview
Control Seat is a split system:
- Editor — a browser-based visual dashboard builder
- Runtime — renders published dashboards with live data
- Tag system — manages live data, tag definitions, and real-time streaming
- Publish service — stores and serves dashboard screens, assets, projects, and gateway scripts
- Gateway worker — runs server-side automation scripts
- Historian — records and queries historical tag data via ClickHouse
How It Fits Together
Editor (browser)
→ Publish service for saving/publishing dashboards
→ Tag system for live data and bindings
Published Dashboard (browser)
→ Publish service for loading the screen
→ Tag system WebSocket for live data updates
Gateway Scripts (server-side)
→ Tag system for reading/writing tags
→ PostgreSQL for script state and logs
Infrastructure
Control Seat runs on AWS:
| Resource | Detail |
|---|---|
| Compute | ECS Fargate |
| Database | RDS PostgreSQL (schema-per-tenant isolation) |
| Historian | ClickHouse Cloud (database-per-tenant) |
| CDN | CloudFront for static assets |
| Proxy | OpenResty with service discovery |
| Connection pooling | PgBouncer |
Multi-Tenant Isolation
Each workspace gets isolated infrastructure:
- Database: Separate PostgreSQL schema per tenant
- Historian: Separate ClickHouse database per tenant
- Networking: Isolated service instances with dynamic port allocation
Security
- Allowlist-based CORS configuration
- Role-based access control with three roles: admin, engineer, viewer
- Permission enforcement on all API endpoints
- Encrypted credentials for data source connections