Custom YAML Examples

Learn how to modify your Job or Microservice Pod YAML to add small but powerful changes that may or may not already be supported in the Shakudo UI. This is the ultimate customization path for users familiar with Kubernetes Pods, containers, and specs.

Note: If a feature exists in the frontend, prefer that path first. Use Custom YAML for advanced overrides where you need full control.

Add a Liveness Probe

Use a liveness probe to automatically restart your container if it becomes unhealthy. You can add probes directly under your container spec in the Custom YAML panel. See additional background in the Service docs - Health Probes.

Example (HTTP GET to /health):

spec:
  template:
    spec:
      containers:
        - name: your-container
          ports:
            - containerPort: 8787
          livenessProbe:
            httpGet:
              path: /health
              port: 8787
            initialDelaySeconds: 30
            periodSeconds: 10
            timeoutSeconds: 5
            failureThreshold: 3

Example (simple TCP socket on the exposed port):

spec:
  template:
    spec:
      containers:
        - name: your-container
          ports:
            - containerPort: 8787
          livenessProbe:
            tcpSocket:
              port: 8787
            initialDelaySeconds: 30
            periodSeconds: 10
            timeoutSeconds: 5
            failureThreshold: 3

Add a Shakudo Secret to a Job or Service

Shakudo Secrets let you pass sensitive data securely to workloads. Start by creating a Secret in the dashboard (see the Secrets docs for details and naming guidance).

When attached via the Shakudo UI, secrets are injected automatically as:

• Environment variables: HYPERPLANE_CUSTOM_SECRET_KEY_{KEY}
• Files: /etc/hyperplane/secrets/{secret_name}/{secret_key}

If you prefer to wire a Kubernetes Secret explicitly in Custom YAML, start by filling in as much of the Jobs or Microservices creation form as you need, then click the "Customize Pod YAML" button and use one of the patterns below (the Secret must already exist in the same namespace as the workload):

Option A — reference a single key as an environment variable:

spec:
  template:
    spec:
      containers:
        - name: your-container
          env:
            - name: API_KEY
              valueFrom:
                secretKeyRef:
                  name: my-secret         # Shakudo Secret name
                  key: api-key            # key inside the secret

Option B — mount the whole secret as files and read from the mount path:

spec:
  template:
    spec:
      containers:
        - name: your-container
          volumeMounts:
            - name: my-secret-vol
              mountPath: /etc/hyperplane/secrets/my-secret
              readOnly: true
      volumes:
        - name: my-secret-vol
          secret:
            secretName: my-secret

Tip: With Shakudo-attached Secrets, your code can also read files directly from /etc/hyperplane/secrets/{secret_name}/{secret_key} or use the auto-injected env var HYPERPLANE_CUSTOM_SECRET_KEY_{UPPERCASE_KEY}.

---

More examples coming soon!