Home
Catalog
PricingPlans and pricing
UpdatesProduct changelog
DocsGuides and API reference
GalleryExample dashboards built with AI
Overview
MissionWhy we're building Control Seat
AboutMeet the team behind it
BlogNews and insights
Pricing
Deployment
CloudWe host and manage
On-premRun on your hardware
ContactDocs

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

Cloud vs Self-Hosted

Control Seat runs in two distinct modes that share the same product surface but differ in deployment, isolation, and licensing.

Cloud (SaaS)

The default. Sign up at controlseat.com, pick a workspace name, and your tenant is provisioned automatically. The cloud SaaS runs on AWS with the infrastructure detailed below. You don't manage servers, certificates, updates, or licenses.

Self-Hosted

For air-gapped environments, customers with strict data residency requirements, or anyone who'd rather run on their own hardware. Self-hosted Control Seat ships as a native installer — .pkg (macOS), .msi (Windows), .deb (Debian / Ubuntu), or .rpm (RHEL / Fedora / Rocky). Each bundles the gateway, publish-service, gateway-worker, and an embedded PostgreSQL database into a single package. Download, double-click, and the gateway opens at http://localhost:8090.

Self-hosted installs add three things that don't exist in cloud:

  • In-place updates — re-download the installer from controlseat.com/download for each version. The data directory carries over.
  • A TLS configuration page — admins upload a PEM cert + key directly from the gateway UI; certs hot-swap without restart.
  • A license system — signed Ed25519 license files (uploaded or activated online) gate the build. There's a 24-hour grace period past expiry to absorb NTP outages. Cloud never runs the license code path.

Docker Compose deployments are also supported for shared infrastructure or fully-offline environments — contact us for an appropriate bundle. See On-Prem Deployment for the full self-hosted operations guide.

Infrastructure

The cloud SaaS runs on AWS:

ResourceDetail
ComputeECS Fargate
DatabaseRDS PostgreSQL (schema-per-tenant isolation)
HistorianClickHouse Cloud (database-per-tenant)
CDNCloudFront for static assets
ProxyOpenResty with service discovery
Connection poolingPgBouncer

Self-hosted installs collapse the same services into a single binary (driverhost) plus an embedded PostgreSQL — same publish-service and gateway-worker code, just colocated.

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
← PreviousGetting StartedNext →Dashboards