Manual Helm reference
This page describes the current worker chart, version 0.3.6. Helm values become environment variables in the worker. Start with Manually manage the analyzer for a complete values file.
Deployment and storage
Section titled “Deployment and storage”Unless noted, Helm keys in this table are under pig. Environment-variable suffixes have the prefix PIG_.
| Helm key | Environment-variable suffix | Meaning |
|---|---|---|
runtimeBaseUrl | RUNTIME_BASE_URL | Optional Promptless endpoint override; defaults to https://api.gopromptless.ai. |
configHash | CONFIG_HASH | Registered configuration hash from Promptless. Coordinate configuration changes with the team. |
storageBackend | STORAGE_BACKEND | postgres_s3, postgres_azure_blob, or postgres_gcs. |
traceObjectS3Bucket | TRACE_OBJECT_S3_BUCKET | S3 bucket for raw ranges and canonical trace objects. Required for postgres_s3. |
traceObjectS3Prefix | TRACE_OBJECT_S3_PREFIX | Object prefix; defaults to trace-objects. Acme uses acme/traces. |
maxTraceBatchBytes | MAX_TRACE_BATCH_BYTES | Maximum decoded trace-batch size, in bytes. Default 268435456 (256 MiB); must be positive. |
logLevel | LOG_LEVEL | DEBUG, INFO, WARNING, ERROR, or CRITICAL. Default INFO. |
The install token and PostgreSQL DSN are also required. They come from Secret references, described below. Keep the database, bucket, and prefix stable across restarts and upgrades. Changing a storage location does not migrate existing data.
The service listens on port 8080 by default. Use that value for service.workerPort and ingress routing in the current chart. The analysis repository mirror uses an ephemeral emptyDir; it can be rebuilt after a restart and does not require a persistent volume. Trace data and analysis state live in your object store and PostgreSQL.
Native storage and workload identity
Section titled “Native storage and workload identity”Select one backend. Keep the relevant values under pig:
pig: storageBackend: postgres_s3 traceObjectS3Bucket: acme-pig-traces traceObjectS3Prefix: acme/tracesGrant the analyzer’s AWS identity access to the bucket and trace prefix. For EKS IRSA, annotate the existing ServiceAccount with eks.amazonaws.com/role-arn and bind its namespace and name in the role’s trust policy.
pig: storageBackend: postgres_azure_blob traceObjectAzureAccountUrl: https://REPLACE_STORAGE_ACCOUNT.blob.core.windows.net traceObjectAzureContainer: traces traceObjectPrefix: acme/tracespodLabels: azure.workload.identity/use: "true"Configure AKS workload identity and annotate the existing ServiceAccount with azure.workload.identity/client-id. Scope the Blob data role to the trace container. The chart applies podLabels to both the analyzer and migration Job.
pig: storageBackend: postgres_gcs traceObjectGcsBucket: acme-pig-traces traceObjectPrefix: acme/tracesConfigure GKE Workload Identity Federation and grant the identity access to the trace bucket. If using IAM service account impersonation, annotate the existing Kubernetes ServiceAccount with iam.gke.io/gcp-service-account and configure its impersonation binding.
The SDK for the selected backend discovers credentials through workload identity. The chart does not accept storage access keys or arbitrary env and envFrom values.
| Helm key | Environment-variable suffix |
|---|---|
traceObjectAzureAccountUrl | TRACE_OBJECT_AZURE_ACCOUNT_URL |
traceObjectAzureContainer | TRACE_OBJECT_AZURE_CONTAINER |
traceObjectGcsBucket | TRACE_OBJECT_GCS_BUCKET |
traceObjectPrefix | TRACE_OBJECT_PREFIX |
These suffixes use the PIG_ prefix. traceObjectPrefix defaults to trace-objects and applies to Azure and GCS. S3 uses traceObjectS3Prefix.
Service account, database TLS, and image
Section titled “Service account, database TLS, and image”The pre-install migration hook runs before Helm creates ordinary resources. Create its ServiceAccount, credential Secret, and CA ConfigMap in the release namespace before you install the chart. The analyzer and the migration Job both use the ServiceAccount named in serviceAccount.name.
| Helm key | Default | Meaning |
|---|---|---|
serviceAccount.create | false | Keep false while migrationJob.enabled is true. The chart fails to render when both are true. |
serviceAccount.name | pig-analyzer | Existing workload identity ServiceAccount for the analyzer and the migration Job. |
migrationJob.enabled | true | Runs schema migrations in a pre-install and pre-upgrade hook Job. |
podLabels | {} | Labels for the analyzer and migration Job pods, such as the Azure workload identity label. |
nodeSelector | {} | Node labels for the analyzer and migration Job pods. On GKE Standard with workload identity, set iam.gke.io/gke-metadata-server-enabled: "true"; omit it on Autopilot. |
pig.postgresCaConfigMapName | Empty | ConfigMap with the trusted database CA bundle. When set, both workloads mount it at /etc/pig/postgres-ca/ca.pem and set PGSSLROOTCERT. |
pig.postgresCaConfigMapKey | ca.pem | Key in that ConfigMap that holds the CA bundle. |
image.repository | ghcr.io/promptless/pig-trace-analyzer | Worker image repository. |
image.digest | Set by the published chart | Verified worker image digest, in the form sha256:<64 lowercase hex characters>. A source checkout requires the digest from the matching release. |
For example, to use an existing pig-analyzer ServiceAccount and a postgres-ca ConfigMap:
serviceAccount: create: false name: pig-analyzerpig: postgresCaConfigMapName: postgres-ca postgresCaConfigMapKey: ca.pemUse sslmode=verify-full in the DSN. See PostgreSQL requirements for TLS and schema permissions.
Health and readiness probes
Section titled “Health and readiness probes”The chart configures these Kubernetes probes for the analyzer:
| Probe | Path | Behavior |
|---|---|---|
| Readiness | /readyz | Gates upload and analysis traffic on recent database and object-storage checks. A storage failure removes the analyzer from Service endpoints until storage recovers. |
| Liveness | /healthz | Fails when the worker’s background tasks stop, or when a storage check or canonical-object repair makes no progress for 180 seconds. Kubernetes then restarts the analyzer. |
| Startup | /healthz | Allows up to 180 seconds for storage to become ready before the liveness probe applies. |
A database or object-storage outage that the analyzer detects makes it unready but keeps it live. The chart’s optional Ingress, enabled with gateway.enabled, exposes /healthz for load-balancer health checks; /readyz stays inside the cluster. The analyzer’s terminationGracePeriodSeconds is 120 seconds, so in-flight work settles during a rollout.
Analysis activation
Section titled “Analysis activation”All Helm keys below are under pig.analysis. The environment-variable suffixes have the prefix PIG_ANALYSIS_.
| Helm key | Environment-variable suffix | Meaning |
|---|---|---|
activationAt | ACTIVATION_AT | Timezone-aware ISO timestamp for enabling analysis. Empty leaves trace analysis inactive. |
quietWindowHours | QUIET_WINDOW_HOURS | Positive quiet period before a session is eligible; default 0.5 hours. |
mirrorRoot | MIRROR_ROOT | Default /var/lib/pig/analysis-mirrors. Keep the default to use the chart’s mounted mirror storage. |
When activationAt is nonempty, configure all model fields below. The worker validates those settings together and refuses partial analysis configuration. Changing the quiet window does not enable analysis by itself.
An organization administrator selects the instruction repositories the analyzer reads in PIG Settings. The analyzer receives GitHub App tokens scoped to Contents read for those repositories from Promptless. The analyzer reads GitHub repositories with a main branch; GitLab publishing support in the hub toolchain does not imply GitLab analyzer or remediation support. See Supported agents and platforms for the separate compatibility boundaries.
Model provider
Section titled “Model provider”These Helm keys are under pig.analysis.modelApi:
| Helm key | Worker environment variable | Meaning |
|---|---|---|
provider | PIG_ANALYSIS_MODEL_PROVIDER | openai, azure_openai, or aws_bedrock. |
authentication | PIG_ANALYSIS_MODEL_AUTHENTICATION | api_key, or aws_sigv4 for Bedrock only. |
baseUrl | PIG_ANALYSIS_MODEL_BASE_URL | Supported HTTPS Responses API endpoint. |
model | PIG_ANALYSIS_MODEL_NAME | Model or deployment name available through that endpoint. Select it explicitly for your account. |
| Provider | Accepted endpoint shape | Authentication |
|---|---|---|
openai | https://api.openai.com/v1 | API key. |
azure_openai | https://RESOURCE.openai.azure.com/openai/v1 or https://RESOURCE.services.ai.azure.com/openai/v1 | API key. |
aws_bedrock | https://bedrock-mantle.REGION.api.aws/v1 or the same host with /openai/v1 | API key or AWS SigV4. |
Replace RESOURCE and REGION. URLs must not contain embedded credentials, an explicit port, query parameters, or a fragment. Ordinary Bedrock Runtime URLs and arbitrary OpenAI-compatible endpoints do not pass the current provider validation. GKE deployments can use one of the supported providers; there is no Vertex AI provider option.
For api_key, supply analysis-model-api-key in the worker Secret. For aws_sigv4, select aws_bedrock, omit the model API key, and grant the worker’s AWS identity access to the selected model. S3 and model authorization are separate permissions even when they use one identity.
The analyzer sends session content and relevant instruction context to this provider. Choose its region and data-handling terms accordingly; see Trust and data model.
Secret references
Section titled “Secret references”Use secrets.existingSecretName to reference a Secret in the worker namespace. The chart defaults to these keys:
| Helm mapping | Default Secret key | Worker environment variable |
|---|---|---|
secrets.installTokenKey | install-token | PIG_INSTALL_TOKEN |
secrets.customerPostgresDsnKey | customer-postgres-dsn | PIG_CUSTOMER_POSTGRES_DSN |
secrets.analysisModelApiKeyKey | analysis-model-api-key | PIG_ANALYSIS_MODEL_API_KEY |
secrets.migrationPostgresDsnKey | none (unset by default) | PIG_MIGRATION_POSTGRES_DSN |
The model key is referenced when an activation time is configured with api_key. The analyzer receives GitHub App tokens for the selected instruction repositories from Promptless, so the worker Secret holds no repository credential.
Set secrets.migrationPostgresDsnKey to run schema migrations with a separate migration credential. The chart injects PIG_MIGRATION_POSTGRES_DSN into the migration Job only; the serving analyzer never receives it. Both credentials must reach the same database over sslmode=verify-full. Leaving this key unset runs migrations with customer-postgres-dsn.
The chart also supports creating a Secret from values, but an existing Secret keeps credential values out of your GitOps configuration. Use your secret-management system to rotate credentials. Restart the worker after updating environment-backed Secret values so the process receives them.
Sentry uses a separate Secret reference. See Sentry error-reporting values.
Datadog tracing values
Section titled “Datadog tracing values”Use these values when your cluster already runs a Datadog Agent that accepts APM traffic. The Helm keys are under observability.datadog:
| Helm key | Default | Meaning |
|---|---|---|
enabled | false | Turns on Datadog tracing and adds log-discovery annotations to the analyzer and migration Job pods. |
env | local | Sets DD_ENV and the tags.datadoghq.com/env label. |
service | pig-trace-analyzer | Sets DD_SERVICE, the tags.datadoghq.com/service label, and the service in log discovery. |
agentUrl | http://datadog-agent.datadog:8126 | Sets DD_TRACE_AGENT_URL. Starts with http:// or https://. |
site | datadoghq.com | Sets DD_SITE. |
For example, with your installation’s Agent URL and site:
observability: environment: production datadog: enabled: true env: production service: acme-pig-worker agentUrl: http://datadog-agent.datadog:8126 site: datadoghq.comWhen Datadog is enabled, the chart also sets DD_TRACE_ENABLED, DD_TRACE_ANALYTICS_ENABLED, and DD_VERSION on the analyzer and the migration Job. The chart sets only these DD_* variables. Configure the Agent’s container-log collection and network access separately.
Analysis tracing can include LLM observability data. Review your telemetry collection and retention settings before enabling it for sensitive sessions.
Sentry error-reporting values
Section titled “Sentry error-reporting values”The Helm keys are under observability:
| Helm key | Default | Meaning |
|---|---|---|
environment | local | Sets SENTRY_ENVIRONMENT. |
sentry.enabled | false | Turns on Sentry error reporting. |
sentry.existingSecretName | Empty | Secret in the release namespace that holds the Sentry DSN. Required when Sentry is enabled. |
sentry.dsnKey | SENTRY_DSN | Key in that Secret that holds the DSN. |
Create the Secret with your secret-management system. For example, with a Secret named acme-pig-sentry that holds the DSN under SENTRY_DSN:
observability: environment: production sentry: enabled: true existingSecretName: acme-pig-sentry dsnKey: SENTRY_DSNThe chart supplies SENTRY_DSN, SENTRY_ENVIRONMENT, and SENTRY_RELEASE to the analyzer and the migration Job. The worker reports errors to Sentry; Sentry performance tracing is off in the worker’s current setup.
Apply a configuration change
Section titled “Apply a configuration change”Render the chart with your values and review the generated references and endpoints. Apply the change through the deployment’s owner: your Helm workflow or its GitOps controller. Don’t let a supervisor manage the same worker resources. Manually manage the analyzer shows the render and install commands.
After rollout, repeat the complete-session verification. Configuration validation and a healthy pod don’t prove that credentials can access the database, bucket, or model.