Installation

Choose a safe Hikyo installation path for local evaluation or production preparation.

Hikyo is in 0.x development and has no published stable release yet. Build from source for evaluation. Do not treat a development build as a supported production release.

Choose an installation path

Goal	Path	Result
Try Hikyo locally	Getting started	Loopback-only server, SQLite, embedded web UI
Try the latest `main` build	Unsigned development snapshot	Exact-commit archive for six desktop/server targets
Build a reusable binary	Build from source	One binary for your current platform
Prepare a real deployment	Self-hosting baseline	Explicit storage, keys, TLS boundary, and backups
Upgrade an existing instance	Upgrades	Pre-migration export and verified rollout

Official release installers are not published yet

The repository contains the signed-release pipeline, installer template, OCI image, and Helm chart. Those become installation options only after a release is published. Development snapshots below are unsigned CI output, not substitutes for that ceremony.

Native packages after a signed release

Published releases include local-install packages for Linux amd64 and arm64: Debian (.deb), RPM (.rpm), Alpine (.apk), and Arch Linux (.pkg.tar.zst). Download the complete release bundle first and verify it against the recovery-signed trust metadata with the release’s pinned verify-bundle.sh. Follow the release verification runbook; do not install a package copied out of an unverified or draft bundle.

After verification, install the matching local file. These examples show amd64 names for version 1.0.0:

sudo apt install ./hikyo_1.0.0_amd64.deb
sudo dnf install --nogpgcheck ./hikyo-1.0.0-1.x86_64.rpm
sudo apk add --allow-untrusted ./hikyo_1.0.0_x86_64.apk
sudo pacman -U ./hikyo-1.0.0-1-x86_64.pkg.tar.zst

--nogpgcheck and --allow-untrusted disable native repository signatures, not Hikyo’s verification. The preceding signed-bundle check is mandatory; hosted Linux repositories and their package-index keys are intentionally not published yet. For arm64, package filenames use arm64 (Debian) or aarch64 (RPM, APK, and Arch).

Each package installs only /usr/bin/hikyo and /usr/share/doc/hikyo/LICENSE. It does not create configuration, generate keys, install a service, or start a server.

After a stable release’s protected tap PR is merged, macOS users can install the same macOS archive bytes through the Homebrew convenience channel:

brew install --cask hikyo-org/tap/hikyo

Homebrew does not verify Hikyo’s pinned signing root. It authorizes the tap/cask and verifies the archive SHA-256 recorded in that cask; compromise of the tap could replace the verification instructions, key, URL, and checksum together. Use the complete signed-bundle verification flow above when the Hikyo-root guarantee is required. The Homebrew path is convenient distribution, not an official fail-closed installer.

Unsigned development snapshots

Every successful trusted main build attaches a 14-day hikyo-development-<commit> artifact to its GitHub Actions run. It contains Linux, macOS, and Windows archives for x86_64 and arm64, plus checksums and an unsigned-development warning. GitHub may require a signed-in account to download Actions artifacts.

Use a snapshot only for evaluation. Its commit is immutable and its checksums detect download corruption, but it has no signed release manifest, official installer, upgrade promise, or production support. The offline signing runbook remains the only path from built bytes to an official Hikyo release.

Local evaluation

Use the source build with hikyo server --dev. Development mode creates its SQLite database and root key in the working directory and listens only on 127.0.0.1:8080.

This path is intended for learning the product. It is not suitable for real secret material or network exposure.

Production preparation

A production-like deployment needs decisions that an installer cannot make for you:

Choose SQLite or PostgreSQL.
Place the 32-byte root key outside the database backup.
Configure native TLS, or terminate HTTPS at a trusted reverse proxy with exact CIDRs.
Configure encrypted exports and run a restore drill.
Record the exact source commit used to build the binary.

Hikyo fails closed when these boundaries are missing. Continue with the self-hosting baseline and server configuration.

Platform support

Source builds follow Go’s supported host platforms. Unsigned development snapshots cover Linux, macOS, and Windows on x86_64 and arm64. Official downloads do not exist until the first signed release is published.

The server is designed to run as one binary. The browser UI is embedded when the binary is built with the ui build tag.