Overview

Tillered Self-Hosted, also known as Arctic, is a self-managed TCP accelerator for distributed Linux hosts. You route the TCP traffic you care about through Arctic, and it carries that traffic between hosts with better performance, raising throughput on long-distance or lossy links. The agent handles this transparently, with no changes to your applications, and you can shape per-service bandwidth on top. Unlike Tillered Cloud, you run and manage the infrastructure yourself, with full control over your routing rules and data path.

Setup is deliberately small. Install the agent on two hosts, add your license, and define two peers and one service. Send the traffic you want to accelerate into the entry host and it comes out the far peer. TCP is the focus; you can optionally route non-TCP traffic such as UDP and ICMP down the same path so everything follows one route, or leave it and accelerate only TCP.

Arctic runs as an agent on each host. You manage a cluster declaratively: describe the peers and services in a YAML compose file and apply it with arctic compose apply, which keeps the desired state in version control. The CLI can also make individual changes when you need a quick adjustment. From there the agents run themselves. They talk to each other to agree on the cluster's state, keep one another in sync, and repair drift on their own if something goes wrong, so you are not hand-holding the cluster day to day.

Key concepts

Arctic is built around three core building blocks:

• Peers are the individual Arctic agents that form your cluster. Each peer runs on a Linux host, holds an Ed25519 identity, and maintains encrypted connections to other peers in the same licensed cluster. See Clustering for how peers discover each other, prove their identity, and converge on shared state.
• Services are the unit of traffic Arctic accelerates. A service carries traffic from a source peer (the entry) to a target peer (the exit), and sets the transport, source-IP handling, and bandwidth for that traffic. It matches the traffic it carries in one of two ways: through its own MACVLAN interface, or through CIDR-based routes. See Service management for how to create and configure services.
• Routes are the CIDR rules a service uses to match traffic by source and destination and direct it to the target peer. Arctic picks the most specific matching route, breaking ties by priority. See Routing for how routes are evaluated and how traffic flows through the overlay.

Every cluster also runs against a license, which sets the cluster identity boundary and bounds its size. See Licensing for how licenses are verified and enforced.

Getting started

Follow these steps to go from a fresh environment to a working Arctic cluster:

1. Check prerequisites - verify system requirements, network ports, and required packages
2. Install Arctic - install the Arctic agent and CLI on your hosts
3. Run the quickstart - define a compose file and deploy your first cluster

Sections

• Getting Started - prerequisites, installation, and quickstart
• Guides - compose files, peer and service management, upgrades, and troubleshooting
• Reference - CLI commands and configuration file reference
• Concepts - clustering, licensing, routing, transparent mode, and deployment modes
• Glossary - definitions for key terms

New to the concepts? Start with Clustering to see how peers find each other and stay in sync, then read Routing to follow a packet through the overlay.