suprsend-values.yaml, and tips for upgrades, rollbacks, and troubleshooting.
Prerequisites
- Kubernetes: A working cluster (managed or self‑managed). Permissions to create namespaces, deployments, services, and ingress.
- kubectl: Configured to point to the target cluster.
- Helm: v3.9+ recommended.
- Ingress & TLS (optional but recommended): Your ingress controller (for example, NGINX, ALB, etc.) and a TLS secret if exposing public endpoints.
- Platform dependencies: SuprSend components expect supporting services (you can bring your own or run them separately):
- PostgreSQL (v17+ recommended; with required extensions)
- Redis / KV-compatible store
- Temporal
- OpenSearch
- NATS (JetStream enabled) - can be installed via the included subchart (see below) or point to an existing NATS cluster.
Step 1: Obtain Your License Token
- Request your license token from SuprSend.
- One token can be reused across environments. You can also request additional tokens if needed.
Step 2: Add the SuprSend Helm Repository
If you need to rotate credentials later, re-run the above command with the new token.
Step 3: Update Your Helm Repositories
Step 4: Create a Dedicated Namespace
Step 5: Create SuprSend Secrets
Fill following file with appropriate values:suprsend-secrets.yaml
Step 6: Install the Chart
Install with a custom values file
Use
--dry-run --debug to validate your configuration before a real install.Step 7: Verify the Deployment
Running or Completed. Investigate any CrashLoopBackOff or ImagePullBackOff with kubectl logs and kubectl describe.
Step 8: Configuration - suprsend-values.yaml
Below is a starter suprsend-values.yaml you can copy and edit. Replace placeholders (hosts, TLS secrets, replicas, etc.) per your environment. The license.token should be set before install/upgrade.
suprsend-values.yaml
Notes on common fields
license.endpointandlicense.token: Set both to enable license verification and chart pulls.serviceAccount: Provide a name to bind specific RBAC, or leave empty to use the default.global.secret.existingKubeSecret: Reference to the Kubernetes secret containing sensitive configuration (for example,suprsend-secrets).global.secret.*Key: Keys in the secret that point to actual secret values (should match keys in your Kubernetes secret).*-api,*-app, andconsumer-*sections: Each component supportsreplicaCount,podLabels,podAnnotations,nodeSelector,tolerations, andaffinity(see detailed explanation below).ingress: For public-facing components, configure:annotations: Object for ingress annotations (for example, cert-manager, load balancer config)ingressClassName: Ingress controller class (for example,nginx,alb)host: Public hostnametlsSecretKey: Name of existing TLS secret
managementService.config: CORS and proxy port for the management API (allowedOrigins,corsDomainWhitelist,port).designerEditor: Ingress and scaling for the designer editor; setglobal.config.suprsendDesignerEditorBaseUrlto match the public URL.nats: Enable the included subchart if you don’t manage NATS externally. Configure:nkey: The public part of your NATS NKey authentication (starts with ‘U’). This must match thenatsNkeyPubKeyin your secrets.- JetStream storage size (default: 20Gi)
- Retention settings via
natsman.config
- WorkOS (optional): For dashboard SSO via AuthKit, set
suprsendapi.config.isWorkosIntegrated,workosClientId, andworkosSigninBaseUrl; mapworkosApiKeyandworkosWebhookSecretKeyin secrets; setsuprsendApp.config.viteDisableWorkosLoginFlowas needed. See WorkOS Integration (SSO).
Advanced Pod Scheduling and Metadata Configuration
Take full control over how each component is deployed within your Kubernetes cluster. These Helm chart values map directly to core Kubernetes concepts, providing fine-grained control over pod scheduling, metadata, and resource placement.Pod Metadata
-
podLabels: Custom labels to add to each component’s pods. Labels are primarily used for selecting and organizing resources.Use this for organizing pods by team, cost tracking, or integrating with your internal monitoring and alerting tools. -
podAnnotations: Custom annotations to add to each component’s pods. Unlike labels, annotations are not used for selection but for attaching arbitrary metadata for tools or operators.This is useful for configuring service mesh sidecars, monitoring endpoints, or other third-party integrations.
Pod Scheduling and Placement
-
nodeSelector: The simplest way to constrain pods to nodes with specific labels. The pod will only be scheduled on nodes that have all of the specified labels.Use this to ensure pods run on nodes with specific hardware or characteristics. -
tolerations: Allows pods to be scheduled on nodes with specific taints. Taints are placed on nodes to repel pods, and tolerations allow pods to “tolerate” those taints.Use this to run workloads on dedicated or specialized node pools that should not run general-purpose workloads. -
affinity: The most powerful and flexible method for defining pod scheduling rules. It allows for complex logic regarding both pod-to-node and pod-to-pod placement.Useaffinityrules to:- Spread pods across nodes or availability zones for high availability (podAntiAffinity).
- Colocate related services on the same node to reduce latency (podAffinity).
- Express complex node preferences that
nodeSelectorcannot (nodeAffinity).
Example: High-Availability Production Configuration
This example demonstrates how to combine these options for a robust production deployment of thesuprsendapi component.
Note on Affinity Rules:
requiredDuringSchedulingIgnoredDuringExecutionis a hard requirement. The pod will not be scheduled unless the rule can be met. This is ideal for critical high-availability rules.preferredDuringSchedulingIgnoredDuringExecutionis a soft preference. The scheduler will try to meet the rule but will still schedule the pod if it cannot. This is useful for optimization rather than for critical guarantees.
Step 9: Subchart Dependencies
SuprSend’s Helm chart includes NATS as an optional dependency:- To install NATS via subchart, keep
nats.enabled: true(default in the sample above). - To use an external NATS, set
nats.enabled: falseand configure your services to point at the external endpoint (env/values not shown here).
Step 10: Upgrades & Rollbacks
Upgrade to the latest chart
Upgrade to a specific version
Roll back to a previous release
Step 11: Uninstall
If you installed the NATS subchart and want to preserve JetStream data, ensure you have backups or snapshots before cleanup.
Best Practices
- Limit repo credentials to CI/CD or admins. Rotate tokens periodically.
- Back up stateful services (NATS JetStream, Postgres, OpenSearch) using your platform’s snapshot/backup tooling.
- Use separate namespaces per environment (dev/stage/prod).
- Resource tuning: Set requests/limits and HPA as you observe load.
- Ingress: Enforce TLS everywhere; prefer DNS-validated certs via cert-manager.
- Observability: Enable centralized logs/metrics and set alerts on queue depth, request latency, and error rates.
FAQ
401/403 when adding repo or installing
401/403 when adding repo or installing
Validate the
--username license and --password (token) passed to helm repo add. Ensure the token is correct and not expired/rotated.Chart not found or old index
Chart not found or old index
Run
helm repo update and retry.Pods stuck in ImagePullBackOff
Pods stuck in ImagePullBackOff
Check image registry reachability, imagePullSecrets (if any), and network egress policies.
CrashLoopBackOff
CrashLoopBackOff
Run
kubectl logs <pod> -n suprsend and check dependent services (Postgres, Redis, Temporal, OpenSearch, NATS). Verify connection URLs and credentials passed via environment/values.Ingress not reachable
Ingress not reachable
Verify DNS points to your ingress controller,
ingressClassName is correct, and TLS secret exists in the suprsend namespace.NATS JetStream storage issues
NATS JetStream storage issues
Adjust
nats.config.jetstream.fileStore.pvc.size (default: 20Gi) and retention settings in natsman.config; monitor PVC usage.