Requirements

What your server needs before you install Dassie on it. Most small Linux servers have all of it already, apart from the domain name and an open UDP port.

The server

• Linux, on x86-64 or arm64. Each release has a bundle for both. There are no releases for other architectures.
• systemd, running. The installer sets up systemd units that start the node, hand it its ports and update it every night. It stops if systemd is not running. With --no-service, it installs Dassie without the units and doesn't need systemd: you run the node under units of your own.
• root, or sudo. The installer writes to /opt/dassie, /usr/local/bin and /etc/systemd/system.
• A clock that keeps time, through systemd-timesyncd, chrony or anything like them. Certificates need it, and so does headless setup, which refuses a phrase that says it was made more than a day after the server's clock.

Each release's installer is tested on these distributions, each in a container with systemd, before the release is signed:

Other distributions with systemd usually work too. On NixOS, use the flake instead of the installer: Dassie on NixOS.

No server? The desktop app runs a node on your own computer, with no domain name and no open ports. A server without a public IP address can run a node too: A server without a public IP.

Tools the installer uses

The installer is a POSIX shell script. It checks for each of these and stops at the first one missing, naming it:

• tar, sha256sum, base64, awk, mktemp and flock
• curl or wget, to download the release
• minisign, or OpenSSL 1.1.1 or later, to check the release's signature. With OpenSSL, the installer reads minisign's format itself, so you don't need to install anything first. Your OpenSSL must be able to compute BLAKE2b-512; if it can't, the installer asks you to install minisign.

Nothing is unpacked before the signature checks out. How that works, and the key itself, are on Release mirror and key.

A domain name

Your node needs a public IP address and a domain name that points to it, such as node.example.com. The node gets its TLS certificate for that name from Let's Encrypt, other nodes find it at https:// that name, and you open your wallet there.

• It must be a DNS name, not an IP address, and at most 242 characters long, so that https://, the name and a port fit in the URL other nodes take.
• Point an A record, an AAAA record or both at the server before you run sudo dassie init.

You can use any domain you control. If you have none, your node can still run as a periphery node: it peers and pays through the core nodes it connects to. Core and periphery explains the difference.

Wallets and apps reach a periphery node at <node ID>.dassiepay.net, through a front door the Dassie project runs. The node keeps a connection to it by default, and you can name another relay, or none (A relay).

Ports

Open these to the internet, in the server's firewall and in your cloud provider's, if it has one:

UDP 443 is the one people miss most often. Nodes talk to each other over QUIC only, so a node whose UDP port 443 is closed cannot be listed by the bootstrap nodes and gets no peers. If another program holds UDP 443 on the server, dassie.service doesn't start at all. Troubleshooting says how to tell.

Why it works this way: QUIC is the only transport between nodes.

The node also connects out: to other nodes over QUIC, on UDP, usually to port 443, and over HTTPS to Let's Encrypt, to get.dassie.land for updates, and to the XRP Ledger server it settles through. The full list, with the paths Dassie uses on disk, is on Files, ports and sockets.