Install Asternodis

Asternodis installs from a single command on any Linux host: your Proxmox node, or a small VM that can reach it. Apart from curl to fetch the installer and OpenSSL 3.0 or newer (shipped by recent Proxmox VE) for the installer to check the release signature, the host needs only the OpenSSH client (ssh), which every Proxmox VE node already has. There is no proprietary agent to push into your guests: Asternodis works through Proxmox’s own API, SSH, and (in VMs that run it) the standard qemu-guest-agent, which Asternodis can install where it is missing.

curl -fsSL https://asternodis.com/install.sh | sh

The installer:

detects your OS/architecture (Linux amd64 or arm64) and downloads the matching static binary;
verifies it before installing anything: the release’s SHA256SUMS must carry a valid Ed25519 signature from the Asternodis release key, and the binary’s SHA-256 must match it. A download that doesn’t verify is refused, and nothing is installed;
puts the verified binary at /usr/local/bin/asternodis;
creates the state directory /var/lib/asternodis;
installs and starts a systemd service that runs the daemon + web UI.

When it finishes it prints the URL to open, which is HTTPS on port 443 with a self-signed certificate on first run:

https://<this-host-ip>

What’s running

Component	Default	Purpose
Web UI / API	`:443` (HTTPS)	The console and REST API you interact with. A `:80` listener redirects here.
Peer link	`:8444` (mTLS)	The authenticated channel between paired sites.
Data dir	`/var/lib/asternodis`	The controller database and keys.

The self-signed cert is fine for evaluation. For production you can supply your own certificate (--tls-cert / --tls-key) or terminate TLS at a proxy. See the CLI reference.

Network ports

The controllers orchestrate, and the replication streams themselves run directly between Proxmox nodes, so node-to-node paths need opening too. Open these at both sites before protecting your first guest:

From → to	Port	Purpose
Browser → controller	TCP `443`, and `80`	Web UI and REST API over HTTPS. `:80` only redirects to `:443`.
Controller ↔ peer controller	TCP `8444`, both directions	Pairing and the mTLS control channel between paired sites (`--peer-listen`).
Controller → Proxmox node you added	TCP `8006`	Proxmox API. Set per cluster.
Controller → Proxmox nodes	TCP `22`	SSH for node operations. Set per cluster.
Primary nodes → recovery nodes	TCP `10800`–`20000`	VM disk replication over `qemu-nbd`: one port per disk, chosen from the recovery site’s range on the recovery node. The range shown is the default; each site sets its own under Settings → Replication data ports.
Recovery nodes → primary nodes	TCP `10800`–`20000`	VM failback, and restore in place: the recovery site streams back into `qemu-nbd` exports on the primary node, one port per disk, chosen from the primary site’s range (the default is the same).
Primary nodes → recovery nodes	TCP `22`	Container replication and failback (`zfs send` or `rsync` over root SSH), and VMs in the optional ZFS-send mode.
Controller → internet	TCP `443`, outbound	License activation and periodic check-in, and update downloads.
DNS clients → recovery node	TCP/UDP `53`	Only when DR DNS is enabled for a pair.
Proxmox nodes → package repositories	TCP `80`/`443`, outbound	Only to install what is missing: a standard Debian package a node lacks, installed with `apt-get`, and `qemu-guest-agent` for a Linux guest, which comes from that guest’s own repositories.
Controller → your webhook endpoints	As configured, outbound	Only with alert webhook delivery or automation hooks.

Node-to-node addresses. A node connects to its counterpart at the address that counterpart’s own controller uses for it, so each site’s node addresses must be routable from the other site.
Node-to-node SSH is always port 22. The per-cluster SSH port applies to the controller’s own connections only. Asternodis authorizes a per-pair key in the recovery cluster’s root authorized_keys for this path.
Which nodes the controller reaches. Other members of a cluster are reached through the node you added. The exceptions are a recovery node that holds replicas and a node you choose as a failback target: the controller reaches those directly at their cluster address.

Manual install

Prefer to place the binary yourself? Download asternodis_linux_amd64 (or asternodis_linux_arm64), mark it executable, and run asternodis serve. A manual download is not signature-checked for you: fetch SHA256SUMS and SHA256SUMS.sig from https://dl.asternodis.com/latest/ into the same folder and, from an already-installed asternodis you trust, run asternodis verify-release --dir . --name asternodis_linux_amd64 (it applies the same check as the installer and the in-app updater). latest is the only published channel today: a version path such as /get/v1.0.16/ returns 404 until that release is published as its own channel. The CLI reference covers the flags.

Next: first run. Set the admin password and walk the onboarding wizard.