High Availability

High Availability turns your single Core into a cluster of up to three Cores that back each other up. The secure network keeps working as long as two Cores are up; the platform applications fail over to a standby automatically within minutes; and your platform's public names follow the active Core on their own.

A Core installed as described in this guide is HA-ready from day one — it already runs as a single-member cluster, and the DNS records you created during the first rollout are exactly the delegation High Availability builds on. Enabling HA is therefore simply a matter of adding Cores.

Before you start

Two additional appliances that meet the Core requirements, each with its own public IP.
UDP and TCP port 53 open to every Core's public IP — each Core answers DNS for your platform's zone. If port 53 is blocked by a firewall or security group, clients cannot resolve the cluster.
Access to your DNS provider to add records to the parent zone.

You can review your platform's DNS records anytime via the DNS delegation records button in the High Availability section of your Core's detail panel — Cansole verifies each record live and marks it Found in DNS or Not found in DNS. The HA Core option in the Infrastructure app's + menu stays disabled until the delegation verifies, and tells you what's missing.

Add the second and third Core

For each additional Core, one at a time:

1. Generate a join token in Cansole

In the Infrastructure app: + → HA Core, enter a Node Name (e.g. core-02), and create. A join token is shown — like enrollment tokens, it is displayed only once; copy or download it.

2. Join the new appliance

Boot the new appliance, configure its network in the device console, and open its rollout page (https://<appliance-ip>:8443). Choose Core, then Join existing network (HA Core).

On the "Join an existing Core cluster" page:

Paste the Cluster Join Token.
Check This Core's public IP — it is auto-detected; correct it if the appliance is behind NAT. It must be the address clients reach this Core at.

Click Join Cluster. The join runs automatically — the new Core pulls everything it needs securely from the cluster; there is nothing to copy manually. When the page reports "Core Cluster Join Completed Successfully!", the node is a standby member and the rollout page disables itself.

3. Add the new Core's DNS records — after the join

The join progress page shows recommended DNS records for the new Core. Add them in the parent zone only after the join has completed — for a node named core-2 on a zone customer.example.com:

customer.example.com.               NS   core-2-customer.example.com.
core-2-customer.example.com.        A    <this Core's public IP>

These are the same kind of NS + glue records you created for the first Core — one redundant name server entry per Core, so DNS keeps answering even if a Core is down.

Add one Core at a time, and never create a Core's NS record before that Core has joined. A record pointing at a Core that isn't serving yet breaks name resolution for your platform.

Repeat steps 1–3 for the third Core.

Operating the cluster

The High Availability panel on any Core's detail page lists every member with a reachability indicator, its role, and version. The Core currently running the platform applications carries the Active badge.

Planned failover: click Set active on another member to move the active role there — for maintenance or rebalancing. The confirmation dialog ("Move the active role?") notes that all application services, including Cansole itself, move over and that the console may be briefly unreachable while services restart. Planned handovers are coordinated so no data is lost.
Automatic failover: if the active Core fails, a standby takes over on its own — applications are typically back within one to two minutes, and at most about five minutes of the very latest changes may be lost. You'll see the event in notifications and the audit log.
Updates: system updates roll through the cluster one Core at a time while the platform stays available — trigger them from Cansole as usual and follow the cluster-wide progress.
Backups and restores are cluster-aware: scheduled backups run from the active Core, and restoring offers a data-only mode that keeps your cluster intact.

Your CanMe environment is now highly available — congratulations.

Implemented in the safest environments.