Glossary

Agent

The Arctic process that runs on each Linux host in your cluster. The agent accelerates the TCP traffic routed through it, manages the encrypted tunnels, and synchronizes state with the other peers. See Installation for how to install the agent.

Audit event

A structured log entry the agent emits for security-relevant activity: a WARN authz_denied event for every rejected request (the subject, the operation, and the required versus held scopes) and an INFO config_change event for every committed configuration mutation (the action, the entity, the acting identity, and what changed). Events are stable JSON keyed by the event field, so they can be shipped to a SIEM as-is. See Monitoring for reading the agent's logs.

Bootstrap

The initial operation that registers an Arctic agent with a license and establishes its identity within a cluster. Bootstrapping is the first step after installing the agent. See CLI reference for the bootstrap command.

Break-glass credential

The admin credential pair a bootstrap mints and shows exactly once. It is written to break-glass.<cluster-id>.json (mode 0600) next to the CLI config, while the config itself keeps only a scoped working credential. Supply the pair via --client-id/--client-secret or ARCTIC_CLIENT_ID/ARCTIC_CLIENT_SECRET for admin-only operations such as credential management, and move the file offline once it is secured. See Credential management for when each credential is used.

Cluster

A group of Arctic agents that coordinate to accelerate TCP traffic between hosts. Cluster membership is defined by the CustomerID carried in the license: two peers merge state only when their CustomerIDs match. Peers in a cluster discover each other, prove their identity, synchronize configuration, and establish encrypted tunnels automatically. See Clustering for how clusters work.

Compose

A declarative configuration format for Arctic deployments. Compose files define peers, services, and routes in a single YAML document, letting you manage your cluster as infrastructure as code. See Declarative Cluster Management for usage.

Fingerprint

The SHA256 hash of a peer's Ed25519 identity key, written as SHA256:.... It is how an agent's TLS identity is verified: the CLI pins fingerprints on first contact, and declaring a fingerprint: per peer in the compose file - optional but recommended for production - lets apply and diff verify a peer's identity before it is ever contacted. Read the value on the trusted host with arctic-agent fingerprint. See TLS and trust for the trust model.

Known hosts

The CLI's trust store at ~/.config/arctic/known_hosts.yaml (mode 0600), recording the pinned Ed25519 identity of every agent it has contacted, in the style of SSH's known-hosts file. The location is independent of --config; place it explicitly with --known-hosts or ARCTIC_KNOWN_HOSTS. A corrupt store fails closed. See TLS and trust for how identities are learned and verified.

License

An Ed25519-signed document that authorizes an Arctic deployment. It supplies the CustomerID that forms the cluster identity boundary, bounds the node and service counts, and sets the enabled feature set. The agent verifies it against keys baked into the binary, at bootstrap and on every startup. See Licensing for verification and enforcement.

License state

The position of a license in its expiry machine: valid, warning, grace period, read-only, or suspended. The state determines what a degraded license still permits, from a warning that changes nothing to a suspended state that stops services. Check it with arctic license status. See Licensing for what each state blocks.

MACVLAN interface

A virtual network interface created by Arctic on a peer to attach services to a dedicated IP address on the host's network. MACVLAN interfaces allow Arctic to receive and route traffic without conflicting with the host's primary network configuration. See Service management for how services use MACVLAN interfaces.

Multipath TCP (MPTCP)

A kernel extension that lets one TCP connection carry data over several network paths at once. A TCP-transport service can opt its tunnel dials into MPTCP with mptcp: {enabled: true} in compose (with an optional subflows count), pairing naturally with device pins on multi-NIC hosts. Dials fall back silently to plain TCP when the kernel or the remote peer lacks MPTCP support. See Transports for when it helps and Uplinks for pairing it with device selection.

Peer

An individual Arctic agent participating in a cluster. Each peer has a unique identity, maintains encrypted connections to other peers, and can host services and routes. See Peer management for how to add and remove peers.

Recovery token

A credential used to reach a peer through its recovery path, written by the agent to /etc/arctic/recovery.token. Peers configured with api_access: internal reject ordinary user-facing requests and are reachable only with a recovery token, which keeps internal-only peers out of the operator surface while still allowing recovery. As of v1.4.2 the token rotates every 24 hours (RECOVERY_TOKEN_TTL) rather than lasting until the next restart, so read the file at time of use; a stored copy stops working after the next rotation. See Access recovery for using it and Clustering for internal-only peers.

Rollback point

A snapshot pair captured into .arctic/backup/ before every non-bootstrap compose apply: a copy of the pre-apply state cache plus a config export of the pre-apply cluster, under one timestamp. arctic state backups lists them and arctic compose rollback applies one, converging the cluster back to its pre-apply configuration. See Backup and restore for the rollback workflow.

Route

A rule within a service that matches traffic by source and destination CIDR and directs it to the target peer. Routes are the CIDR-based way a service classifies traffic; the alternative is a MACVLAN interface. Arctic selects the most specific matching route, breaking ties by priority where a lower value wins. See Routing for how routes are evaluated.

Scoped credential

A credential that holds an explicit set of scopes rather than implicit admin rights. As of v1.4.2 every credentials create must name its scopes (the read, write, and admin aliases cover the common sets), a credential can only grant scopes it holds itself, and bootstrap saves a scoped working credential - enough for routine CLI work, no admin - to the CLI config. See Credential management for scopes and grants.

Service

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 it. It matches the traffic it carries either through a MACVLAN interface or through CIDR routes. See Service management for how to create and manage services.

Snapshot

A copy of the agent's database (arctic.db) written into $DATA_DIR/backup/ on a schedule via SQLite VACUUM INTO, safe while the agent is running, or captured on demand with arctic database snapshot. A snapshot plus peer.key restores a peer as itself after a host rebuild; without one, a rebuilt host comes back as a new identity. See Backup and restore for schedules and restore steps.

Tombstone

A signed marker left behind when a peer or service is deleted, in place of removing the record outright. The tombstone gossips like any other update so the deletion propagates across the cluster, and its signature stops a stale copy from resurrecting the record. Tombstones are pruned 30 days after the deletion. See Clustering for how deletions propagate.

Transparent mode

A feature that preserves the original source IP address when routing TCP traffic through Arctic. By default, the destination sees the exit peer's IP. With transparent mode enabled, the in-process TProxy engine maintains the client's real address all the way to the destination. It applies to TCP only and requires specific kernel settings on the exit peer. See Transparent Mode for details.

Trust-on-first-use (TOFU)

The default trust model for peer TLS: the CLI records an agent's Ed25519 identity the first time it connects and verifies it on every connection after that, so only the very first contact is unverified. Declaring a fingerprint: in the compose file, or pinning one with arctic cluster trust, removes even that first-contact gap. See TLS and trust for the full trust ladder.

Uplink (device pin)

A per-service choice of network device on a multi-NIC or overlay-equipped host. uplink_dev pins the egress device a service's traffic leaves by, and its sibling pins choose the inbound match (routes[].device) and the MACVLAN parent (interface.parent_dev). All three are host-local operator intent, are not gossiped, and can be changed on a live service. See Uplinks for when to use each pin.

Voucher

A short-lived signed statement that lets a peer be trusted before it has completed a direct handshake. If A trusts B and B vouches for C, then A accepts C: the voucher carries C's public key and is signed by B. Vouchers have a 24-hour TTL by default and are refreshed within a 6-hour window of expiry. See Clustering for how vouchers establish transitive trust.