Minithor utilizes Minikube to provide a local Kubernetes instance with minimal custom configuration required. Such an instance is useful for development and testing of Thorium as well as small stand alone analyst fly-away kits where external network access may not be available. Minithor deployments are not highly available distributed systems like our production instances and provides minimal redundancy. The Thorium deployment produced by following these instructions should be considered Beta. We will work to improve its stability over time. While a Minithor deployment is accessible only from your localhost, all backing-service passwords are randomly generated per deploy. The default admin user password can be randomized with --rand-password.

To deploy Minithor, you will need a container runtime such as that provided by the docker engine or podman. KVM/libvirt (kvm2 driver) is also supported on Linux. Minithor automatically selects the best available driver in order of preference: podman > docker > kvm2. Minithor also requires a relatively beefy machine, with 16+ GiB of memory, 8+ CPUs, and 100GiB of local storage.

All lifecycle operations are available through the minithor CLI. The script reads input files from your current working directory by default and can be installed globally (e.g. /usr/local/bin/minithor).

minithor — manage a local Thorium instance on Minikube

Usage: minithor <command> [options]

Commands:
  minikube         Manage the minikube cluster (install, delete)
  start            Start a previously stopped minikube cluster
  deploy           Deploy all Thorium services and backing infrastructure
  get-config       Extract the running Thorium config to ~/thorium.yml
  expose           Port-forward Thorium (and optionally backing services) to localhost
  stop             Stop the minikube cluster (preserves state)
  cleanup          Remove all Thorium resources for a fresh deploy (requires --confirm)

Global options:
  -h, --help       Show this help message

Run 'minithor <command> --help' for command-specific options.

When running minithor commands, the following files are looked for in your current working directory:

All paths can be overridden with CLI flags — run minithor <command> --help for details.

Install and start minikube and any necessary plugins.

minithor minikube install [--cpus <n>] [--memory <n>] [--certs-dir <path>]

If the Thorium container image is hosted in a private registry, create a .dockerconfigjson file in your working directory containing the registry credentials. The deploy command will detect this file and create a Kubernetes image pull secret automatically.

docker login registry.domain:port
cp ~/.docker/config.json .dockerconfigjson

If omitted, the operator will pull images without authentication (works for public registries like ghcr.io).

If your organization maintains a proxy for all traffic going to the internet, export proxy settings before running the deploy command:

export HTTP_PROXY=<HTTP_PROXY_URL:PORT>
export HTTPS_PROXY=<HTTPS_PROXY_URL:PORT>
export NO_PROXY=localhost,127.0.0.1,10.0.0.0/8,192.168.0.0/16

Or use the provided proxy file: source proxy

The deploy command handles the full deployment in a single step: all backing services (Redis, Elasticsearch, ScyllaDB, MinIO, Postgres, Quickwit, Jaeger), the Thorium operator, the ThoriumCluster resource, and a default test user.

minithor deploy [options]

This will:

1. Wait for the minikube cluster to be healthy
2. Install Helm and add required chart repos
3. Deploy Redis, Elasticsearch (ECK), cert-manager, ScyllaDB, MinIO, Jaeger, Kubegres, and Quickwit
4. Configure databases (Scylla roles/keyspace, Elasticsearch index/user, MinIO buckets)
5. Deploy the Thorium operator and create the ThoriumCluster CRD
6. Wait for all Thorium components (API, scaler, event-handler, search-streamer) to be running
7. Create an admin user (default: test / INSECURE_DEV_PASSWORD, customizable via --user / --password / --rand-password)
8. Install thorctl to the bin directory and import the default toolbox
9. Create a static group and an allow-all network policy
10. Optionally deploy a container registry with persistent storage (if --registry or --registry-user is specified)

All backing-service passwords (Redis, Scylla, Elasticsearch, MinIO, Postgres, and the Thorium API secret key) are randomly generated per deploy using a cryptographically secure RNG. These passwords are not displayed during deployment but can be retrieved afterward with minithor get-config.

To customize the ThoriumCluster configuration, provide your own config file:

minithor deploy --config path/to/thorium-cluster.yml

Port-forward the Thorium API to localhost:

minithor expose [--dev] [--port <port>] [--stop] [--status]

The registry service (port 5000) is also forwarded by default when a registry has been deployed. Port-forward logs are written to /tmp/minithor-expose-logs/.

Then open http://localhost:8080 in your browser and log in with the credentials shown at the end of the deploy output (default: test / INSECURE_DEV_PASSWORD).

Extract the running Thorium config from the cluster:

minithor get-config
# Writes thorium.yml to ~/thorium.yml

Stop the minikube cluster while preserving its state:

minithor stop

Resume later with minithor start.

Restart a previously stopped cluster:

minithor start

Remove all deployed Thorium resources and backing services for a fresh deploy. The --confirm flag is required:

minithor cleanup --confirm

This removes all namespaces, Helm releases, CRDs, and cluster-level RBAC created by the deploy step. Individual step failures are logged but do not abort the cleanup. The minikube cluster itself is preserved.

Completely remove minikube, its data, and associated binaries. The --confirm flag is required:

minithor minikube delete --confirm

This runs minikube delete --all --purge, removes ~/.minikube and ~/.kube, uninstalls the minikube and kubectl binaries, and prunes unused container images. This is irreversible.