Installation

This guide walks through a fresh, single-host installation of Manifest Self-Hosted using the manifest-installer CLI. One Linux host runs the entire stack: the k3s control plane, the Manifest applications, and the supporting services. The same host is also where you run manifest-installer itself.

These steps cover an internet-connected install. If your target host cannot reach the internet, follow the Air-Gapped Deployments workflow instead — it uses the same CLI but adds steps to bundle and transfer the install artifacts.

📘

Versions

Installer releases are published on the manifest-self-hosted Releases page. Replace <version> in the commands below with the version you've been instructed to install (e.g. 2.0.0); the release tag is that version prefixed with v.

Prerequisites

Before proceeding, ensure you have:

• Met all host and network requirements
• Gathered all required credentials

1. Install the CLI

The manifest-installer binary is published to the public manifest-self-hosted Releases and is downloadable anonymously — no GitHub account or token required. Each binary ships with a matching .sha256 checksum file.

Download the binary and its checksum, verify, then place it on your PATH:

base=https://github.com/manifest-cyber/manifest-self-hosted/releases/download/v<version>
curl -fsSL -O "$base/manifest-installer-linux-amd64"
curl -fsSL -O "$base/manifest-installer-linux-amd64.sha256"
sha256sum -c manifest-installer-linux-amd64.sha256   # prints "OK" on a match
chmod +x manifest-installer-linux-amd64
sudo mv manifest-installer-linux-amd64 /usr/local/bin/manifest-installer

The binaries are not code-signed today — verify the checksum to confirm integrity.

Verify the install:

manifest-installer --version

The CLI follows the XDG Base Directory Specification, splitting its files into three locations by purpose:

Export any of the XDG_*_HOME variables before running the CLI to relocate that directory — for example, to put downloaded packages on a mounted volume, export XDG_DATA_HOME=/mnt/manifest-data.

2. Configure AWS credentials

The installer pulls platform packages from Manifest's private ECR registry (623542229617.dkr.ecr.us-east-1.amazonaws.com) in us-east-1. Configure the IAM credentials Manifest provided during onboarding using either of the following.

Option A — persist them via the installer CLI (recommended for hosts without an AWS CLI or environment configured):

manifest-installer config set aws.accessKeyID <provided-by-manifest>
read -rs SECRET_ACCESS_KEY   # paste the secret access key; input is not echoed
printf %s "$SECRET_ACCESS_KEY" | manifest-installer config set aws.secretAccessKey

The secret is piped on stdin rather than passed as an argument — when the value is omitted, config set reads it from stdin, keeping the secret out of shell history and ps output. The values are written to ~/.config/manifest/installer-config.yaml (mode 0600); do not edit the file by hand. Region is derived from the registry URL; you do not need to set it. Only long-lived IAM-user keys are accepted — for short-lived STS credentials, use the environment-variable path below.

Option B — export them in the environment (useful for one-off runs and for rotating without persisting):

export AWS_ACCESS_KEY_ID=<provided-by-manifest>
export AWS_SECRET_ACCESS_KEY=<provided-by-manifest>
export AWS_REGION=us-east-1

Environment variables and any other AWS SDK credential source (~/.aws/credentials, IRSA, IMDS) take precedence over the persisted values, so an emergency credential swap does not require re-running config set.

3. Download platform packages

Pull the platform packages into ~/.local/share/manifest/versions/<x.x.x>/:

# Latest version
manifest-installer download

# Or pin a specific version
manifest-installer download --version <x.x.x>

In an internet-connected install you don't need to download reference data — the platform ingests vulnerability and metadata feeds directly from their sources at runtime.

4. Set up the deployment

Run the interactive setup wizard:

manifest-installer setup

You'll be prompted for deployment-specific values such as the base domain, the administrator email, and (optionally) SMTP, OIDC, and CA certificate settings. On re-runs, the prompts default to your previous answers, so you can hit Enter to accept or type a new value to change it. The Configuration Reference describes the wizard, where your answers are stored, and how to change them later.

📘

If the wizard renders incorrectly

Over a serial console, a limited SSH client, or a screen reader, the full-screen interface can render garbled. Run TERM=dumb manifest-installer setup to get the same questions as a plain line-by-line prompt flow with no screen redrawing.

Every answer — plus a set of workload credentials the installer generates for you (database passwords and similar) — is written to a single file, ~/.config/manifest/config.yaml. config.yaml is the single durable copy of these values — back it up after setup and after any later configuration change. Because sensitive values live in this file, the wizard asks you to make a deliberate encryption choice before it writes anything; see Encryption & Key Management for the choices and the consequences of key loss.

5. Deploy

Deploy the platform:

manifest-installer deploy

deploy runs against the packages downloaded in step 3 and the configuration written in step 4. If either prerequisite is missing, deploy stops with a pointer to the missing step — it never silently runs download or setup on your behalf.

deploy performs the following, in order:

1. Host preparation — installs OS prerequisite packages, loads required kernel modules (br_netfilter, overlay), applies sysctl settings, opens firewall ports (6443 for the k3s API, 31999 for the Zarf registry, 80/443 for Traefik), and applies SELinux/nftables/fapolicyd rules where applicable.
2. k3s installation — installs the k3s binary and systemd service. k3s embeds containerd as its container runtime, so no separate container engine is needed.
3. In-cluster registry bootstrap — Zarf injects a temporary seed registry into the cluster, then promotes a permanent in-cluster registry. All container images for the platform come from this in-cluster registry, not from the public internet.
4. Platform deployment — brings up Manifest itself: platform-level dependencies and operators, then the application workloads.

A first-run deploy typically takes 10–20 minutes, depending on image-pull speed and host performance.

deploy is safe to re-run from the top. If it fails partway through, fix the underlying issue and re-run the same command — each step is idempotent and the previously-completed work is detected as a no-op, so a re-run converges to the failed point in seconds. There are no checkpoint files to clean up and no special "resume" flag.

When the deploy completes successfully, the command exits with code 0 and the final line of output confirms the last package deployed and its version:

deployed package manifest-app, version <x.x.x>

deploy does not print the platform URL — verifying the install and reaching the web UI are covered next.

6. Verify the install

📘

status command

The manifest-installer status health-report command is not yet available in this release. Until it ships, verify the install with kubectl as below.

Point kubectl at the new cluster and confirm pods are healthy:

export KUBECONFIG=$HOME/.kube/config
kubectl get nodes
kubectl get pods -A

All pods should reach Running or Completed. Confirm Traefik is listening:

kubectl -n traefik get svc

Then resolve your domain to the host IP (via DNS or a temporary /etc/hosts entry) and visit the URL in a browser. Signing in for the first time and trusting the generated CA certificate are covered in Post-Install.

Next Steps

• Complete the Post-Install steps: first login and certificate trust
• Review the Configuration Reference for the setup wizard values and day-2 configuration changes
• To update to a newer release later, see Upgrade
• If you encounter issues, see the Troubleshooting Guide