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​

note

Self-hosting the Tower Runner is a feature that is in private beta. If you're interested in using the Tower Runner in a self-hosted mode, please contact Tower support (hello@tower.dev).

  • 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

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-managed 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: Installing Self-Hosted Data Plane​

Prerequisites​

Before installing the Tower Runner, ensure you have:

  • A Tower account and API key
  • System requirements:
    • x86_64 or ARM architecture
    • Internet connectivity to *.tower.dev
  • One of the following:
    • Debian/Ubuntu Linux for .deb packages
    • RHEL/CentOS/Fedora Linux for .rpm packages
    • Docker for container deployment
    • Root or sudo access for system package installation

Installation Steps​

The Tower Runner can be installed using one of three methods:

  1. Debian/Ubuntu Package (.deb)

Coming soon

  1. RPM Package (.rpm)

Coming soon

  1. Docker Container

Coming soon

Configuration​

After installation, configure the runner with your Tower API key:

# For package installations
tower-runner configure --api-key your_api_key_here

The runner service will automatically start after configuration. Verify the installation with:

tower-runner status

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.