Plan the service around your KubeVirt clusters

Shepherd adds request, review, access and audit workflows around KubeVirt. Operating that service requires decisions about persistence, credentials, cluster connectivity and ownership. Start with a test environment and the published Alpha boundaries.

Browser demo · No account · Simulated data

Check the published Helm package before choosing a version

KubeVirt Shepherd source on GitHub main, a published application release and the Helm repository are separate delivery tracks. Inspect the package you will actually install instead of assuming that a main-branch feature is already released.

helm repo add kv-shepherd https://kv-shepherd.github.io/helm-charts
helm repo update kv-shepherd
helm search repo kv-shepherd/shepherd --versions
helm show chart kv-shepherd/shepherd
helm show values kv-shepherd/shepherd

The add/update commands maintain local Helm repository configuration and cache. The remaining commands inspect metadata and defaults; none installs a release or contacts your Kubernetes cluster. Record the chart version, appVersion and image settings. After review, pin that chart with --version and use the matching release documentation. Optional metrics and monitoring resources depend on the chosen package, not only on what exists on main.

Choose an intentional installation path

Helm is the Kubernetes-native path. Docker Compose can run published release images on a host, or build from a checkout when that is deliberate. The chart and Compose release path use different image defaults; follow the instructions for the mode you choose.

Plan state and recovery

PostgreSQL 18 stores application state and River background jobs. Redis and a separate queue are not default runtime requirements. Plan persistent storage and backup, plus recovery of the configuration needed to decrypt stored infrastructure credentials.

Evaluate the scope you actually need

The project is Alpha. It does not replace KubeVirt, Kubernetes operations or every feature of a larger virtualization distribution. Validate the request, placement, permissions and console paths your team needs, with the monitoring setup described in the operator documentation.

Walk through the task

  1. Define one representative workflow

    Choose a service, requester, reviewer and test namespace. Describe the expected request, operation and audit outcome before installing.

  2. Choose Helm or Compose

    Use the chart for a Kubernetes installation or release-image Compose for a host. Source-build mode requires a checkout and is a separate choice.

    Read the deployment paths
  3. Prepare persistence and recovery

    Review database storage, bootstrap credentials and required secrets before exposing the service. Preserve the values needed to decrypt stored infrastructure data.

    Read generated credentials and recovery
  4. Connect and validate a test environment

    Configure cluster access, catalogs, namespaces and account assignments. Run the full request-to-execution flow, inspect audit evidence and test the intended monitoring and recovery setup.

    Read observability scope and boundaries

Requirements and limits

  • Alpha suitability depends on your clusters, authentication, storage and operating policies.
  • The lightweight Helm example disables database persistence for demonstration; a persistent service needs its own storage and recovery configuration.
  • Source development requires Go 1.25.12 or newer and Node.js 22 or newer. These build prerequisites are separate from running published images.
  • Capabilities described in main-branch documentation may require a later application or chart release. Inspect the exact package and its supported configuration.

Documentation and implementation

Common questions

Are Go and Node.js needed to run release images?

Those prerequisites apply to source development. Follow the Docker and access requirements for the published-image Compose path.

Does Shepherd install a whole virtualization platform?

No. It operates around configured Kubernetes/KubeVirt clusters. You own the infrastructure and the service’s persistence, security and recovery choices.