Skip to main content
This guide walks you through installing SuprSend on Kubernetes using Helm. It includes the exact commands, a ready‑to‑edit 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.
For production, consider managed offerings from your cloud provider for critical data services.

Step 1: Obtain Your License Token

  1. Request your license token from SuprSend.
  2. One token can be reused across environments. You can also request additional tokens if needed.
You’ll use this token to authenticate to the private Helm repository.

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
and create it by

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

Wait for all pods to be 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.
Not a full chart default: this starter does not list every key from the current Helm chart. For example, the Unlayer email editor in the dashboard requires suprsendApp.config.viteEmailEditorToken (request the token from SuprSend). Download or inspect the latest values.yaml bundled with the chart (helm show values suprsend/suprsend after adding the repo) and merge any missing features into your file.
suprsend-values.yaml

Notes on common fields

  • license.endpoint and license.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, and consumer-* sections: Each component supports replicaCount, podLabels, podAnnotations, nodeSelector, tolerations, and affinity (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 hostname
    • tlsSecretKey: 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; set global.config.suprsendDesignerEditorBaseUrl to 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 the natsNkeyPubKey in your secrets.
    • JetStream storage size (default: 20Gi)
    • Retention settings via natsman.config
  • WorkOS (optional): For dashboard SSO via AuthKit, set suprsendapi.config.isWorkosIntegrated, workosClientId, and workosSigninBaseUrl; map workosApiKey and workosWebhookSecretKey in secrets; set suprsendApp.config.viteDisableWorkosLoginFlow as 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.
    Use affinity rules 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 nodeSelector cannot (nodeAffinity).

Example: High-Availability Production Configuration

This example demonstrates how to combine these options for a robust production deployment of the suprsendapi component.
Note on Affinity Rules:
  • requiredDuringSchedulingIgnoredDuringExecution is a hard requirement. The pod will not be scheduled unless the rule can be met. This is ideal for critical high-availability rules.
  • preferredDuringSchedulingIgnoredDuringExecution is 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: false and 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

Validate the --username license and --password (token) passed to helm repo add. Ensure the token is correct and not expired/rotated.
Run helm repo update and retry.
Check image registry reachability, imagePullSecrets (if any), and network egress policies.
Run kubectl logs <pod> -n suprsend and check dependent services (Postgres, Redis, Temporal, OpenSearch, NATS). Verify connection URLs and credentials passed via environment/values.
Verify DNS points to your ingress controller, ingressClassName is correct, and TLS secret exists in the suprsend namespace.
Adjust nats.config.jetstream.fileStore.pvc.size (default: 20Gi) and retention settings in natsman.config; monitor PVC usage.