Skip to main content

Data Plane

Tower's uses a modern distributed system architectural pattern that separates the control plane from the data plane. This design gives your data apps improved scalability, enhanced security, and greater flexibility while ensuring they remain resilient in a serverless environment.

The data plane is responsible for processing customer data, while the control plane manages metadata about applications that allows Tower to provide its services.

Overview​

Control Plane​

The control plane is the centralized management layer of Tower that:

  • Handles user authentication and authorization
  • Manages encrypted application packages and secrets
  • Orchestrates workload scheduling
  • Provides the user interface, API endpoints and CLI interactions
  • Monitors overall system health and metrics
  • Stores encrypted packages and environment data (e.g. secrets, catalogs, etc.)

The control plane does not process customer data in any way.

Data Plane (Tower Runner)​

The data plane is powered by the Tower Runner - a specialized program that:

  • Securely communicates with the control plane to receive jobs
  • Downloads and decrypts application packages
  • Executes Python code in a sandboxed environment
  • Handles data processing and workload execution
  • Cleans up after application execution
  • Maintains security boundaries for workload isolation

Deployment Options​

Tower offers two primary deployment options for the data plane:

1. Data Plane in Tower Cloud​

  • Fully managed by Tower
  • Automatic scaling and maintenance
  • Zero infrastructure management required
  • Built-in high availability
  • Pre-configured sandboxed Python environment
  • Ideal for teams that want a hands-off approach

2. Self-Hosted Data Plane​

  • Deploy in your own cloud or on-premises infrastructure
  • Complete control over the runtime environment
  • Enhanced data privacy and security
  • Ability to access private networks and resources
  • Custom resource allocation
  • Same secure packaging and execution model as cloud runners
  • Windows service support and Linux systemd service for unattended operation

Setting Up the Data Plane​

Option 1: Using Tower Cloud Data Plane​

The Tower Cloud Data Plane is the default option for Tower. Unless you configure a Self-Hosted runner, Tower will dispatch all of your runs automatically to the Tower Cloud data plane and automatically scale up and down on demand.

Option 2: Using a Self-Hosted Data Plane​

note

If you want to use Tower's Self-Hosted runners, you need to be on a plan that supports this feature! Upgrade your plan or contact Tower support for more information.

Prerequisites​

To operate a Self-Hosted Data Plane, you need to install Self-Hosted Tower runners on one or multiple devices.

Before installing a Tower Runner on a device, ensure that you have:

  • A Tower account and API key
  • System requirements:
    • x86_64 or ARM architecture
    • Internet connectivity to *.tower.dev
  • Root or sudo access for system package installation

Self-Hosted Data Plane mode ensures that all runs for your account execute exclusively on your own Self-Hosted runners. It can be enabled in the UI by navigating to Settings → Self-Hosted Runners.

Behavior​

Tower's control plane will only dispatch runs to Self-Hosted runners that belong to your account. If no such runners are connected, runs will remain queued until a runner comes online (they will not fall back to Tower Cloud).

Use cases:

  • Data privacy and sovereignty requirements
  • Access to private/on-prem resources
  • Custom hardware (e.g., high-memory, GPU)

Install and configure Self-Hosted runners​

For installation and configuration steps for Linux, macOS, and Windows, as well as where to download the runner, see our guide on how to install and run Self-Hosted runners.

Environment Variables​

The Tower Runner supports configuration through environment variables:

  • TOWER_ENVIRONMENT: Specifies the environment for the runner (e.g., production, staging, development). Then runs created in that environment will only run on a runner with a matching environment.

Security and Configuration​

Encryption​

Tower implements multiple layers of encryption to ensure the security of your applications and data:

  • Application Package Encryption: Before storage, all application packages are encrypted using AES-256-GCM encryption with unique keys per account. This ensures that your source code and application assets remain confidential, even when stored in Tower's infrastructure managed by Tower.

  • Secret Management: All secrets are protected using envelope encryption:

    • Each secret is encrypted with a unique data encryption key (DEK)
    • The DEK is then encrypted with your account's key encryption key (KEK)
    • Secrets are only decrypted within the runner environment at runtime
    • See our Security documentation for more details on envelope encryption

  • Runtime Security:

    • Decryption of packages and secrets occurs only within the secure runner environment
    • Encryption keys are never stored on disk and are kept in memory only for the duration of the run
    • After each run, all decrypted data is securely wiped from the runner environment

Network Security​

Tower implements strict network security measures to protect all communications:

  • Control Plane Communication:

    • All runner-to-control-plane communication uses TLS 1.3
    • Mutual TLS (mTLS) authentication ensures only authorized runners can connect
    • All API endpoints require authentication using runner-specific credentials

  • Network Requirements:

    • Outbound connections to *.tower.dev on ports 443 (HTTPS) via TCP for gRPC communication
    • No inbound connections are required
    • Proxy support available for enterprise environments
    • Optional VPC/VNET peering for cloud deployments

  • Network Isolation:

    • Each runner operates in its own network namespace
    • Network access can be restricted using standard firewall rules
    • Support for custom DNS configuration

Runner Security​

The Tower Runner implements multiple security measures to ensure safe execution of code:

  • Sandboxed Environment:

    • Resource limits enforced for CPU, memory, and disk usage
    • File system access is restricted to the application's working directory

  • Runtime Isolation:

    • Separate user contexts for each application
    • Private Python virtual environments per run
    • No shared state between different applications
    • Network isolation between concurrent runs

  • Cleanup Procedures:

    • Automatic removal of all application data after execution
    • Secure wiping of sensitive data from memory and disk
    • Regular rotation of runner credentials
    • Automatic termination of long-running processes

  • Package Integrity:

    • Cryptographic verification of downloaded packages
    • Package signature validation before execution
    • Version pinning for reproducible runs
    • Automatic security scanning of dependencies

Monitoring and Management​

Coming soon

Best Practices​

Coming soon

Troubleshooting​

Getting Help​

  • Contact Tower support for assistance
  • Check the documentation for updates

Conclusion​

The separation of control and data planes in Tower provides a flexible, secure, and scalable architecture for your workflow needs. With end-to-end encryption, secure runners, and flexible deployment options, Tower ensures your applications run reliably while maintaining the highest security standards.