← All products

Tillered Self-Hosted

A self-managed overlay networking product connecting distributed Linux hosts through encrypted tunnels.

Overview

Tillered Self-Hosted (Arctic) is a self-managed overlay networking product that connects distributed Linux hosts through encrypted tunnels. Agents run on each host, forming peer-to-peer clusters via shared licence credentials.

The system is built around three building blocks:

  • Peers are the agents running on each host. They form the nodes of the overlay network.
  • Services define traffic policies, specifying how traffic should be handled between peers.
  • Routes are matching rules that determine which traffic is captured and directed through services, based on destination IPs, subnets, or ranges.

Key characteristics

  • CLI and declarative YAML compose file management
  • Peer-to-peer clustering with encrypted tunnels
  • Route-based traffic policies (destination IPs, subnets, ranges)
  • Transparent TCP proxying with source IP preservation
  • Linux hosts (x86_64 and ARM64), macOS CLI support
  • No external control plane dependency
  • Works fully offline in air-gapped networks

Architecture

In Tillered Self-Hosted deployments, agents on each host form a peer-to-peer cluster using shared licence credentials. There is no externally hosted control plane. Peers discover each other and establish encrypted tunnels, creating an overlay network that operates entirely within customer infrastructure.

Tillered Self-Hosted architecture
No external control plane. Peers form a decentralised cluster through encrypted tunnels.

Services define how traffic is handled between peers, and routes determine which traffic is captured based on destination IPs, subnets, or ranges. TCP traffic is transparently proxied with source IP preservation, so applications and destinations see standard TCP connections.

Management model

Tillered Self-Hosted supports two management approaches: imperative CLI commands for direct control, and declarative YAML compose files for infrastructure-as-code workflows.

  • Any node in the cluster can accept management commands
  • Declarative compose files define the desired state of peers, services, and routes
  • Changes propagate across distributed peers with eventual consistency
  • Operation in disconnected environments without external dependencies
  • Incremental system build-out and flexible deployment topologies

Who this is for

  • Government and defence environments
  • Critical infrastructure operators
  • Highly regulated industries
  • Disconnected or intermittently connected networks
  • Organisations requiring full operational autonomy

Getting access

Tillered Self-Hosted documentation is available at docs.tillered.com. For licensing and deployment enquiries, contact our team.