Configuration Reference

This page describes how a Manifest Self-Hosted deployment is configured: the setup wizard, the configuration file it writes, and how to change values after the platform is running. For the install workflow itself, see the Installation Guide.

The Setup Wizard

manifest-installer setup interactively prompts 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.

📘

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.

Where Configuration Is Stored

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 (file mode 0600, inside a 0700 directory). That includes the sensitive values: the SMTP password, the OIDC client secret, the license key, and the generated workload passwords. config.yaml is the single durable copy of these values — it is the artifact to back up and protect. The wizard asks you to make an encryption choice before it writes anything; see Encryption & Key Management for the choices and the consequences of key loss.

Changing Configuration After Install

Change values by re-running the wizard (prompts default to your previous answers) or by editing the file directly with deploy-config edit, then re-run deploy to apply the changes to the running platform:

manifest-installer setup        # or: manifest-installer deploy-config edit
manifest-installer deploy

Re-running deploy at the same version applies only what changed and does not restart healthy workloads.

Maintaining config.yaml

The deploy-config command groups the maintenance operations over config.yaml:

manifest-installer deploy-config validate                  # check completeness; offers to fill defaults and newly required values
manifest-installer deploy-config edit                      # decrypt into your editor, re-encrypt on save
manifest-installer deploy-config rekey --age <age1...>     # add a recipient (second operator or escrow key)
manifest-installer deploy-config encrypt --age <age1...>   # encrypt a plaintext config.yaml after the fact
manifest-installer deploy-config decrypt                   # print the decrypted config to stdout (reveals secrets)

If your ops team prepares config.yaml on another machine, copy it into ~/.config/manifest/ (together with its key file, if setup generated a password-protected key), then run manifest-installer deploy-config validate to confirm it is complete for the version you're deploying.

Host Configuration

Storage Configuration

Most deployments need a single filesystem. Give / the whole disk. The totals in Requirements cover everything listed below.

The platform writes to these paths:

/var/lib/rancher and /var/lib/kubelet must be on the same filesystem, and need at least 200 GB between them. /var/log/pods may be a separate filesystem, and is on a STIG-partitioned host.

Storage needs will increase over time with use. The kubelet manages garbage collection of container images using k3s defaults.

STIG Compliance

Manifest Self-Hosted supports deployment on STIG-hardened systems. The setup wizard includes a STIG-hardened option; when enabled, deploy applies the SELinux, nftables, and fapolicyd host components appropriate for the hardened host.

• SELinux: Supported on RHEL 9, including enforcing mode
• AppArmor: Supported on Ubuntu 24.04 and Debian 12

Where the STIG requires /var on its own filesystem, mount it nodev. Do not mount it noexec or nosuid: the container runtime executes binaries from beneath the cluster data directory, and either option prevents the platform from starting. Use nofail on every non-root entry in /etc/fstab, or a single bad entry drops the host to emergency.target.

FIPS 140 Compatibility

Manifest Self-Hosted supports FIPS 140 installs. A FIPS install runs RKE2 in place of k3s and uses FIPS-built container images, which ship as a separate package set (download --flavor fips). The host must already be running in FIPS mode; the installer does not enable it. Answer yes to FIPS 140 compliant install in the setup wizard, and deploy refuses to run if the downloaded packages do not match that answer. See Installation → FIPS 140 installs.

If you have additional questions about STIG-hardened deployments, FIPS 140-3 cryptography, or other compliance requirements, contact Manifest Cyber at [email protected].

OIDC Configuration

Manifest Self-Hosted natively supports Microsoft, Keycloak, and Google OIDC providers. Other providers are supported but require providing a base64-encoded mapper configuration for Kratos. All providers require the following information.

Configuring the Redirect URI

To finish configuring your OIDC provider, you must add a redirect URI (callback URI) to your OIDC application. For the Manifest platform, the redirect URI is:

https://auth.<domain>/self-service/methods/oidc/callback/<provider-id>

Replace <domain> with your Manifest deployment domain and <provider-id> with the Provider ID you configured.

Related Documentation

• Encryption & Key Management - How secrets in config.yaml are encrypted
• Post-Install - First login and certificate configuration
• Troubleshooting - Common configuration issues and solutions