Configuration Reference

This page describes the configuration values that the installation wizard prompts for, and how to change them after the platform is running. For the install workflow itself, see the Installation Guide.

Changing Configuration After Install

manifest-installer stores configuration in an encrypted file under ~/.manifest/deployment/<name>/. To change a value, use the config subcommand and then re-run an upgrade against the current version to apply it:

manifest-installer config <key> <value>
manifest-installer upgrade --to <current-version>

manifest-installer status shows the current bundle version and deployment state.

Host Configuration

Storage Configuration

The following volume layout is recommended for production deployments:

Volume	Size	Mount Point	Purpose
Root	50-100 GB	`/`	Operating system, `/etc`, `/usr`, `/bin`
Persistent Data	600 GB+	`/var/lib/rancher/k3s/storage/`	Kubernetes persistent volumes

For larger deployments or environments with high data retention requirements, consider the following expanded layout:

Volume	Size	Mount Point	Purpose
Root	30-50 GB	`/`	Operating system, `/etc`, `/usr`, `/bin`
Runtime	100-200 GB	`/var/lib/rancher/k3s/`, `/var/lib/kubelet/`, `/var/log/`	k3s data, kubelet runtime, logs
Persistent Data	600 GB+	`/var/lib/rancher/k3s/storage/`	Kubernetes persistent volumes

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 installation is compatible with:

SELinux: Permissive mode supported on RHEL 9 (enforcing will be supported in the future)
AppArmor: Supported on Ubuntu 24.04 and Debian 12

No additional configuration is required for hardened systems. The k3s installation automatically detects and configures the appropriate security module.

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.

Name	Description	Example
Provider	Name of OIDC provider (must be one of `microsoft`, `keycloak`, or `google`; otherwise a custom mapper url is required)	`microsoft`
Provider ID	Unique name of OIDC provider	`microsoft`
Friendly Name	Name that's displayed for users at sign-in (e.g. "Login with Microsoft")	`Microsoft`
Client ID	Client ID for OIDC application (may be called "application id")	`abcd-1234-efgh-5678`
Client Secret	Secret value for OIDC application	`xyz-098-qrs-765`
Issuer URL	Unique URL that identifies the OIDC provider (you can find this from your applications `.well-known/openid-configuration` endpoint)	`https://login.microsoftonline.com/tenant-id/v2.0`
Mapper URL	Base64-encoded JSON snippet for mapping provider details to Kratos (leave blank for default providers)	`base64://bG9jYWwgY2...`
Requested Scopes	OIDC scopes that may be requested from the provider (leave blank for default providers)	`openid,email,profile,offline_access (optional)`

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.