Skip to main content
This page covers the main Newt Kubernetes configuration options for Helm and Kustomize workflows. For exhaustive option coverage, refer to the chart resources:

README

values.yaml

values.schema.json

Version context

This page is aligned with the Newt Helm chart 1.4.0. Chart 1.4.0 also publishes the Newt image metadata for Docker Hub and GHCR and includes Artifact Hub signing metadata.

Configuration sections

Image and global defaults

Use global.image to control the Newt container image used by all instances.
Recommendations:
  • Leave tag empty to use the chart appVersion.
  • Use digest when you need immutable image pinning.
  • Use imagePullSecrets when pulling from a private registry.
  • Use per-instance overrides only when allowGlobalOverride is enabled for that instance.
The chart can render Namespace resources, including Pod Security Admission labels.
Recommended production pattern:
  1. Create the namespace manually.
  2. Apply required Pod Security Admission labels or policy labels.
  3. Install the chart into that namespace.
Example namespace labels:
Per-instance namespace overrides are available when allowGlobalOverride: true is set:
Creating the namespace manually is recommended when your cluster uses Pod Security Admission, policy labels, admission webhooks, or namespace annotations.
For production, use an existing Kubernetes Secret.
Create the Secret before installing the chart:
The default Secret keys are:
Use auth.keys.* only when your Secret uses different key names:
auth.keys.* are Secret key names, not credential values.Inline credentials are supported, but should only be used for local testing:
Inline credentials can appear in rendered manifests and Helm release history. Use auth.existingSecretName for production.
Do not commit plaintext credentials to Git. For GitOps workflows, use encrypted or external secret backends such as SOPS, Sealed Secrets, External Secrets Operator, Vault, or Infisical.
Chart 1.4.0 also includes auth.createSecret and auth.envVarsDirect modes for generated Secret and direct environment-variable workflows. Use these only when they match your operational model.
Provisioning supports installs where Newt bootstraps credentials from a provisioning key.Use provisioning when Newt should bootstrap credentials from a provisioning key instead of using a static NEWT_ID and NEWT_SECRET.
Provisioning requires writable config persistence so Newt can store the generated configuration.For durable storage, use an existing PVC:
You can also provide a provisioning blueprint:
Each Newt instance is configured under newtInstances[].
Key settings:
Newt 1.11 changed upstream ping defaults. Set pingInterval and pingTimeout explicitly if you need older timing behavior.
Service exposure is controlled separately from acceptClients.
Important behavior:
  • acceptClients does not create a Service.
  • newtInstances[].service.enabled controls whether a Service is created.
  • Tester port exposure is disabled by default unless enabled through test settings or explicit legacy tester-port configuration.
Common Service types:
Use configPersistence when Newt needs writable configuration storage.
Storage types:Provisioning-based installs should enable config persistence. For production provisioning, prefer a PVC over emptyDir.
emptyDir is recreated when a pod is replaced. Newt can require a reconnect and handshake after restart, which may briefly interrupt active traffic.
For production, prefer an existing PersistentVolumeClaim to keep writable Newt configuration across restarts and rescheduling.
The chart supports blueprints, provisioning blueprints, mTLS certificate mounts, Docker socket mounts, and up/down scripts.Blueprint example:
Provisioning blueprint example:
mTLS using an existing PEM Secret:
Up/down scripts:
Use Secrets for certificates and sensitive script inputs. Avoid inline private keys or credentials in values files.
ServiceAccount creation is enabled by default.
RBAC is disabled by default in chart 1.4.0:
Enable RBAC only when your selected configuration needs Kubernetes API permissions:
Per-instance ServiceAccount overrides are available when allowGlobalOverride: true is set:
Chart 1.4.0 changed the RBAC default to rbac.create=false. Existing installations that relied on auto-created RBAC must opt in explicitly during upgrade.
Global resource requests and limits apply to Newt workloads.
Scheduling defaults:
Pod Disruption Budget:
Recommendations:
  • Start with the chart defaults.
  • Increase requests and limits based on traffic volume.
  • Use node selectors, tolerations, affinity, or topology spread constraints when you need placement control.
  • Enable a PodDisruptionBudget only when your replica count and maintenance policy support it.
Avoid CPU limits unless you explicitly need hard caps. CPU limits can trigger throttling even when spare node CPU exists. For most deployments, use CPU requests and memory limits as the starting point.
Health probes are disabled by default.
Per-instance health options:
Helm test jobs are disabled by default:
Enable tests only when you want chart test jobs and tester-port related resources.
Metrics are disabled by default.
The default adminAddr is :2112, which listens on all interfaces and allows in-cluster scraping. Use 127.0.0.1:2112 only when scraping from other pods is not required.Metrics Service:
Prometheus Operator resources:
Example with ServiceMonitor:
Optional pprof endpoint:
NetworkPolicy rendering is disabled by default.
Per-instance NetworkPolicy overrides:
Modes:Enable DNS egress rules if your default network policy blocks DNS.

Configuration by install method

Helm

Use a values file:
Use inline values only for small tests:
See Site (newt) Helm for the installation flow.

Kustomize

Render the chart with Helm, then use Kustomize overlays:
Then apply an overlay:
See Newt Kustomize for the Kustomize workflow.

GitOps

Store Helm values or Kustomize overlays in Git. Argo CD or Flux reconciles the desired state. Argo CD Helm example:
Flux HelmRelease example:
See GitOps for GitOps guidance.

Next steps

Helm Install

Install Newt with Helm.

Kustomize Install

Install Newt with rendered manifests and Kustomize overlays.

Troubleshooting

Debug Newt deployment and connection issues.

GitOps

Deploy Newt with Argo CD or Flux.