There are two ways onto an Alpymist system, and neither is a script piped into a shell. Boot
the installer image, or add the signed repository to an Alpine machine you already have.
Young software. It installs and it runs, and it will have rough edges. Try it in
a virtual machine, or on hardware you do not need tomorrow.
Available
Installer image
Every release has an ISO for each architecture attached, with its SHA-256 checksum: x86_64 for laptops and PCs, and aarch64 for virtual
machines on Apple silicon Macs, such as UTM.
Check the download against its checksum, with both files in the same directory:
sh
❯ sha256sum -c alpymist-*.iso.sha256
The checksum is published beside the image, so it says the download is intact, not who
made it. The packages an installed system upgrades from are signed; the image is not yet.
What the installer asks
Keyboard, region, network, which disk and whether to encrypt it, and the first account.
It then says how Hyprland will do on the machine, and why. Nothing is written to the disk
until you confirm on the last screen. The root account is locked, and
administration is through doas with your password.
In a virtual machine with a virtio-gpu display, the installer offers to draw with the
host's graphics card. That takes a Mesa from a second repository, which is its own decision and can be declined.
Or build it yourself
make iso builds the same image in an Alpine container, and make smoke boots it in QEMU. Building from source →
Available
On an existing Alpine v3.24 system
Trust the Alpymist key, add the repository and refresh the index. Alpymist is built against
Alpine v3.24, and the repository only serves that release.
sh
❯ doas wget -O /etc/apk/keys/alpymist-2026.rsa.pub https://pkgs.alpymist.org/alpymist-2026.rsa.pub❯ echo https://pkgs.alpymist.org/v3.24/alpymist | doas tee -a /etc/apk/repositories❯ doas apk update
Ask the probe how Hyprland will run on the machine, then add the desktop:
sh
❯ doas apk add alpymist❯ alpymist probe❯ doas apk add alpymist-desktop
The ISO's installer also enables dbus, seatd and greetd and points the login screen at the right session. On an existing system
that part is up to you for now.
Check the key before you trust it
The downloaded key should have this SHA-256 fingerprint, which matches the copy in the source
repository at aports/alpymist-keys:
An image is for installing, not for upgrading. An installed system upgrades with doas apk upgrade -U, or Update in the menu, from the channel it follows:
Channel
Moves
Repository
stable
At each release. What the installer sets up.
https://pkgs.alpymist.org/v3.24/alpymist
dev
On every push to main.
https://dev.pkgs.alpymist.org/v3.24/alpymist
sh
❯ alpymist channel❯ doas alpymist channel dev❯ doas alpymist channel stable
The first says which channel the system follows. Following dev trusts its key and upgrades;
going back to stable distrusts the key again and downgrades to the release. The dev key is
shipped where apk does not look, so a system that never asked for dev does not trust it.
The reasoning is in ADR 0006.
What the signature does and does not say
The repository's index is signed, and it pins the hash of every package, so apk refuses a
package that was swapped or changed after the index was made. Stable's index is signed by
CI, on a Release run of a tagged commit on main: what is signed is what was
built in the open.
What that does not give is a person between a release and your machine. The signing key
was once kept offline and is now held by GitHub Actions, so anyone following either channel
is trusting that. ADR 0002 and its addenda record
the trade, and what was given up for it.