Architecture
Control plane
Architecture, deployment options, and operational characteristics of the Datamotive control plane.
- Product
- Datamotive Platform
- Version
- v1.0
- Documentation status
- Published
- Last updated
- Updated
- Reading time
- 2 min read
The control plane is the management brain of Datamotive. It schedules jobs, stores metadata, serves the API, and sends notifications. Its deployment model (SaaS, self-hosted, or sovereign) is the primary factor that determines data residency.
SaaS control plane
In the SaaS model, Datamotive operates the control plane. It runs in AWS us-east-1 with active-active failover to eu-west-1. Availability is 99.9% per month, backed by the Datamotive SLA. Updates are applied automatically with no downtime window required from the customer.
Tenant isolation is enforced at the API layer (JWT claims), database layer (schema-per-tenant with row-level security), and encryption layer (separate DEK per tenant). Datamotive employees cannot access customer metadata without a support request and explicit customer authorization.
Self-hosted control plane
System requirements
| Resource | Minimum | Notes |
|---|---|---|
| vCPU | 4 | Scales linearly with job concurrency |
| RAM | 8 GB | 16 GB recommended for 500+ VMs |
| Disk (control plane) | 50 GB SSD | OS and application binaries |
| Disk (PostgreSQL) | 100 GB SSD | Grows with job history and recovery point index |
| OS | Ubuntu 22.04 LTS or RHEL 8+ | Container runtime required (Docker or containerd) |
| Network | 1 Gbps | To Replication Appliance and Cloud Connector nodes |
High availability
For production self-hosted deployments, run two control plane instances in active-passive mode behind a load balancer. PostgreSQL should use streaming replication with automatic failover (Patroni or managed RDS/Azure Database for PostgreSQL).
The control plane is stateless except for the database: all API server instances share the same database. Deploying multiple API server replicas behind a load balancer provides horizontal scale for API reads and failover for API writes.
Upgrades
Self-hosted control planes are upgraded manually. Datamotive publishes new releases as signed container images. The upgrade process:
- Pull the new image on the control plane host
- Run the pre-upgrade health check script (validates database schema compatibility)
- Restart the container with the new image
- Verify all nodes reconnect and jobs resume
The upgrade typically completes in under 5 minutes. Nodes continue executing in-progress jobs during the upgrade and reconnect automatically when the control plane is back online.
Sovereign control plane
The sovereign control plane is identical to self-hosted in deployment but has two additional constraints:
- No external API calls are made after initial installation (no update checks, no telemetry, no license validation via internet)
- License validation uses an offline activation file refreshed annually through a physical transfer process
Refer to the Sovereign cloud deployment guide for the sovereign-specific installation procedures.
Node connectivity model
Nodes (Replication Appliances and Cloud Connectors) initiate all connections to the control plane. The control plane never initiates a connection to a node. This means:
- No inbound firewall rules needed on any node
- Nodes behind NAT or in air-gapped networks can connect as long as TCP 443 outbound is allowed
- Nodes that lose connectivity to the control plane continue executing their current job and queue status updates for delivery when connectivity is restored
Related docs
Was this page helpful?