Running Mocko

Kubernetes with Helm

The Helm chart is the recommended way to run Mocko in a cluster. One install gives you the mock server, the control panel, a Redis with a persistent volume, and all the wiring between them. This is the setup for staging environments where a whole team points their services at Mocko.

Install

The chart lives in the mocko-app/mocko repository under helm-charts/mocko:

$git clone https://github.com/mocko-app/mocko.git

$helm install mocko ./mocko/helm-charts/mocko

The defaults are a working team setup: one core replica, the control panel, and an internal single-replica Redis backed by a 1Gi PersistentVolumeClaim. The release notes print the port-forward commands; for a quick look without an ingress:

$kubectl port-forward svc/mocko-control 6625:6625

The values that matter

A values file for a typical staging install, with the settings you are most likely to touch:

core:
  replicas: 2
  # Proxy unmatched requests to the real backend (empty disables proxying).
  proxyUrl: "http://my-api.staging.svc.cluster.local"
  timeoutMillis: 30000

control:
  enabled: true

persistence:
  redis:
    enabled: true
    internal:
      enabled: true
      storage: 1Gi

core.replicas: scale the mock server for heavier test traffic. Replicas share state through Redis, so anything above 1 needs persistence enabled.
core.proxyUrl: the cluster-internal equivalent of the CLI's -u flag.
control.enabled: false drops the UI entirely for file-mocks-only deployments.

Shipping file mocks

Committed mock files reach the cluster in two ways:

Drop .hcl files into the chart's mocks/ folder before installing (core.fileMocks.chartFolder.enabled, on by default), or
Point core.fileMocks.existingConfigMap at a ConfigMap you manage yourself, which fits GitOps flows where the mocks live in another repo. Both sources can be active at once.

For large or fast-moving mock sets, skip ConfigMaps and bake the files into a custom image (FROM ghcr.io/mocko-app/core:2, then COPY mocks/ /var/mocks/) as shown on Docker Images, and set core.image.repository to your image.

Using your own Redis

Disable the internal Redis and point the chart at an existing instance. Credentials can come from a Secret instead of values:

persistence:
  redis:
    enabled: true
    internal:
      enabled: false
    # url: "rediss://:password@my-redis:6379/0"
    existingSecret:
      name: "my-redis-secret"
      urlKey: "redis-url"
    # Namespace Mocko's keys when sharing the Redis with other services:
    prefix: "mocko:"

Both redis:// and TLS rediss:// URLs are supported, and prefix keeps keys isolated when the Redis is shared, including between two Mocko releases.

Behavior details

The chart generates the deploy secret connecting control to core and reuses it across upgrades; you never handle it manually.
Liveness and readiness probes are preconfigured against /__mocko__/health (core) and /api/health (control).
Resource requests and limits ship commented out in values.yaml with sane starting points; set them before giving a whole team access.
control.v1Migration.enabled reveals the v1 migration operations in the management page. Leave it off unless you are actively migrating; see Migrating from v1.