Deploying Tines with Helm

Tines can be deployed to Kubernetes using our official Helm chart. This guide covers everything required to configure, install, upgrade, and uninstall Tines using Helm.

We highly recommend sharing this page early with your internal IT/infrastructure/network admin teams to provision the infrastructure and services required before beginning the installation.

Before you begin

The following must be in place before installing the Helm chart:

A running Kubernetes cluster (AWS EKS, Azure AKS, Google GKE, or equivalent)
Helm v3 installed and configured
kubectl configured to communicate with your target cluster
Access to the Tines image registry — see below
A StorageClass in your cluster that supports ReadWriteOnce persistent volumes (the chart defaults to gp3)

Tines image registry

Tines self-hosted artifacts are delivered as a set of Docker images hosted at registry.tines.com. Access to this registry is required before the Helm chart can be installed.

Please contact your Account Executive or Customer Success Manager to obtain your registry credentials. You will receive:

Your tenant name, used as the registry username
A Tines Container Registry API key, used as the registry password

Full details on available images and registry operations are available in the Tines image registry documentation.

Verify registry access

Before proceeding, confirm your credentials are working:

echo $TINES_REGISTRY_KEY | docker login registry.tines.com \
  -u <your-tenant-name> \
  --password-stdin

💡 Note

Customers who maintain a local registry mirror loaded with Tines-provided images may update the deployments.*.image.registry values in their values.yaml to point at their internal registry instead.

Add the Helm repository

helm repo add tines https://helm.tines.com
helm repo update

To confirm the charts are available:

helm search repo tines

Configure your values.yaml

Create a local values.yaml to override the chart defaults. The sections below cover the values that must be set before installation.

Registry credentials

The chart creates a Kubernetes image pull secret from these values. They must be set or the chart will be unable to pull images from registry.tines.com.

tinesContainerRegistryCredentials:
  registry: registry.tines.com
  username: <your-tenant-name>
  password: <your-registry-api-key>
  email: <your-email>

App secret token

This must be set to a random 128-character string. The chart will fail to render if this value is not provided. You can generate a suitable value by running:

openssl rand -hex 64

tinesApp:
  serverConfiguration:
    APP_SECRET_TOKEN: "<128-character-token>"

Initial tenant configuration

These values are used to seed the first tenant and admin user on initial installation. They include the domain where your Tines instance will be accessible, and the credentials for the first user.

💡 Note

Values in initialTenantConfiguration are only read on the first deployment. If you need to change these values after the initial installation, you will need to update the application or database directly.

tinesApp:
  initialTenantConfiguration:
    DOMAIN: tines.your-company.com
    SEED_EMAIL: admin@your-company.com
    SEED_EMAIL_PASSWORD: <password>
    SEED_FIRST_NAME: Admin
    SEED_LAST_NAME: User
    TENANT_NAME: your-company-name

Database

Tines uses Postgres 14.x as its persistent data store. By default, the chart deploys a Postgres container. We highly recommend using a dedicated hosted service (e.g. AWS RDS, Azure Database for PostgreSQL, Cloud SQL) where possible to simplify scaling and backups.

DATABASE_USERNAME and DATABASE_PASSWORD are required values — the chart will fail without them.

tinesApp:
  databaseConfiguration:
    DATABASE_HOST: db
    DATABASE_NAME: tines_production
    DATABASE_USERNAME: tines
    DATABASE_PASSWORD: <password>
    DATABASE_POOL: 20
    DATABASE_PORT: 5432

To use an external database instead of the bundled container, set db.create: false and point DATABASE_HOST at your managed endpoint:

db:
  create: false

tinesApp:
  databaseConfiguration:
    DATABASE_HOST: my-postgres.example.com
    DATABASE_NAME: tines_production
    DATABASE_USERNAME: tines
    DATABASE_PASSWORD: <password>

Redis

Tines uses Redis 6.x as its cache, in-memory datastore, and queuing mechanism. By default, the chart deploys a Redis container. We highly recommend using a dedicated hosted service (e.g. AWS ElastiCache, Azure Cache for Redis) where possible to simplify scaling.

To use an external Redis instance, set redis.create: false and update REDIS_URL:

redis:
  create: false

tinesApp:
  redisConfiguration:
    REDIS_URL: redis://my-redis.example.com:6379/0

SMTP server

Tines can be connected to a customer-provided SMTP server to send emails related to user management, monitoring, notifications, and to power the Send Email action. SMTP configuration is required to send the invitation email to the first user, unless SEED_EMAIL_PASSWORD is set, which bypasses the email invite flow.

tinesApp:
  emailConfiguration:
    SMTP_SERVER: smtp.your-company.com
    SMTP_DOMAIN: your-company.com
    SMTP_USER_NAME: smtp-user
    SMTP_PASSWORD: <password>
    # SMTP_PORT: "587"
    # SMTP_AUTHENTICATION: login
    # SMTP_ENABLE_STARTTLS_AUTO: true

Persistent volumes

The chart provisions several persistent volume claims (PVCs). Your cluster must have a StorageClass that supports ReadWriteOnce access mode. The default values reference gp3 — update storageClassName in your values.yaml to match what is available in your environment.

The following PVCs are created depending on your configuration:

If you are using managed services for PostgreSQL and/or Redis, set db.create: false and/or redis.create: false respectively

💡 Note

Persistent volume claims are not deleted when running helm uninstall. This is intentional. See the Uninstalling section for steps to remove them manually if a full teardown is required.

Load balancer

Customers may choose to either use the nginx container we provide or use dedicated load balancing infrastructure (e.g. AWS ALB, Azure Application Gateway, GCP Cloud Load Balancing) to route traffic to the web server component.

By default, the chart deploys the Tines nginx container and exposes it as a NodePort service on ports 30080 (HTTP) and 30443 (HTTPS). TLS can be terminated at nginx by providing a certificate and key directly.

Alternatively, the chart includes an optional Kubernetes Ingress resource that routes traffic directly to the web server on port 3000, bypassing the built-in nginx container. This is the recommended approach when using a cloud-native load balancer.

💡 Note

When enabling the Ingress resource, we recommend setting nginx.enabled: false to avoid running both the built-in proxy and an external load balancer simultaneously.

Option A — Nginx with TLS termination

Provide your certificate and key directly in values.yaml:

nginx:
  enabled: true
  tinesCrt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  tinesKey: |
    -----BEGIN PRIVATE KEY-----
    ...
    -----END PRIVATE KEY-----

Option B — External load balancer via Ingress

nginx:
  enabled: false

ingress:
  enabled: true
  className: nginx
  annotations:
    # --- AWS ALB ---
    # kubernetes.io/ingress.class: alb
    # alb.ingress.kubernetes.io/scheme: internet-facing
    # alb.ingress.kubernetes.io/target-type: ip
    # alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
    # alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:region:account:certificate/id

    # --- Azure Application Gateway ---
    # kubernetes.io/ingress.class: azure/application-gateway
    # appgw.ingress.kubernetes.io/ssl-redirect: "true"

    # --- GCP Cloud Load Balancing ---
    # kubernetes.io/ingress.class: gce
    # networking.gke.io/managed-certificates: my-cert
  hosts:
    - host: tines.your-company.com
      paths:
        - path: /
          pathType: Prefix
  tls:
    - secretName: tines-tls
      hosts:
        - tines.your-company.com

Installing

Once your values.yaml is ready, create a dedicated namespace and install the chart:

kubectl create namespace tines

helm install tines-app tines/tines \
  -n tines \
  -f values.yaml

On first installation, the chart runs a one-time Kubernetes Job named tines-app-setup that runs database migrations, seeds the initial tenant configuration, and syncs integration templates. You can monitor it with:

kubectl get jobs -n tines
kubectl logs -n tines job/tines-app-setup

Once the setup job completes successfully, confirm all pods are running:

kubectl get pods -n tines

Upgrading

To upgrade to a newer chart version or apply configuration changes, first pull the latest chart index and then run helm upgrade:

helm repo update

helm upgrade tines-app tines/tines \
  -n tines \
  -f values.yaml

To upgrade to a specific chart version:

helm upgrade tines-app tines/tines \
  -n tines \
  -f values.yaml \
  --version 38.4.1

💡 Note

helm upgrade does not re-run initialTenantConfiguration. Those values are only applied on the first installation. All other configuration changes — SMTP, database settings, feature flags, etc. — are picked up on every deployment or pod restart.

If an upgrade needs to be rolled back:

helm rollback tines-app -n tines

Uninstalling

To remove the Helm release and all associated Kubernetes resources:

helm uninstall tines-app -n tines

💡 Note

Persistent volume claims are not removed by helm uninstall. If a full teardown is required, delete them manually after uninstalling:

kubectl delete pvc -n tines \
  db-data \
  redis-data \
  tines-command-runner-data \
  pypi-server-data

To remove the namespace entirely:

kubectl delete namespace tines

Optional components

Tines Tunnel

Tines Tunnel enables connectivity from your Tines Cloud instance to services running inside private networks. Please contact your Account Executive or Customer Success Manager to confirm this feature is included in your product license before enabling it.

To enable Tines Tunnel via the main chart:

tinesTunnel:
  create: true

Customers may also deploy Tines Tunnel as a standalone chart:

helm install tines-tunnel tines/tines-tunnel \
  -n tines \
  --set tunnelSecret=<your-tunnel-secret>

Command-over-HTTP

Command-over-HTTP enables running commands on remote machines via an HTTP bridge. Please contact your Account Executive or Customer Success Manager to confirm this feature is included in your product license before enabling it.

To enable Command-over-HTTP via the main chart:

commandOverHttp:
  create: true
  tunnelSecret: <your-cohttp-secret>

Customers may also deploy Command-over-HTTP as a standalone chart, which additionally supports Kerberos and PowerShell configuration:

helm install tines-cohttp tines/tines-cohttp \
  -n tines \
  --set cohttpSecret=<your-cohttp-secret>

Available charts

Tines Application

tines/tines

Command-over-HTTP

tines/tines-cohttp

Tines Tunnel

tines/tines-tunnel

By product

Professional services

Partners

Tines Blog →

Case studies

Library

University

Tines Explained ↗

Customer center

Careers

About

Tines Store ↗

Deploying Tines with Helm

Before you begin

Tines image registry

Verify registry access

💡 Note

Add the Helm repository

Configure your values.yaml

Registry credentials

App secret token

Initial tenant configuration

💡 Note

Database

Redis

SMTP server

Persistent volumes

💡 Note

Load balancer

💡 Note

Option A — Nginx with TLS termination

Option B — External load balancer via Ingress

Installing

Upgrading

💡 Note

Uninstalling

💡 Note

Optional components

Tines Tunnel

Command-over-HTTP

Available charts

Further resources

Tines Explained ^↗

Tines Store ^↗