Kubernetes

The operator acts like a SRE inside your own cluster, properly deploying and configuring the various Speedscale components.

The Speedscale Kubernetes Operator works similarly to a service mesh controller like Istio or Linkerd. It waits for deployments to be applied to the cluster that contain specific annotations. It then automatically stands up an isolation test environment around the deployment. The operator itself is a deployment that will be always present on the cluster.

Looking to install the operator? The fastest way is to let your coding agent install it. Prefer to install manually? Follow the step-by-step instructions in Quick Start – Install Speedscale Operator.

If your installer can only write in one existing namespace, use the namespaced mode of the same public chart. It creates no Speedscale CRD, admission webhook, or cluster-scoped RBAC.

Platform teams reviewing what the chart creates or changes can use the Helm install and upgrade lifecycle. It separates chart-managed resources, pre-install hooks, Kubernetes actions, and operator-managed runtime components.

For additional background and architecture, complete the Quick Start first, then return here for conceptual details about how the operator works within your cluster.

Kerberos cloud proxy

If your outbound proxy requires Kerberos, follow Kerberos proxy authentication to configure the operator override and mount credentials. The operator propagates these settings to forwarder and inspector.

Private registry images

If your organization requires approved Redis or Java runtime images, configure replayComponents.redis.image and jks.image in your Helm values. The Helm values reference covers runtime requirements and truststore behavior, with a private registry example for Artifactory.