Skip to main content
Your values.yaml holds the whole configuration. The chart’s defaults work out of the box; set only what you want to change.

​
Apply changes

Upgrade with the same files:
Agent hosts read their configuration when they start. After a change that reaches them, such as the GitHub App, your hostname or the database, replace the running hosts. The pool launches new ones, with Tembo’s latest agent host image:
Replacing a host ends the sessions running on it. Replace hosts when they’re idle.

​
License key

To keep the key out of your values, put it in a Kubernetes Secret and reference it:

​
Ingress

The chart serves Tembo through one Ingress at ingress.host, over HTTPS. On AWS, the load balancer uses your ACM certificate for the host. With another Ingress controller, set ingress.tls.secretName to a TLS Secret. The load balancer is internet-facing, so GitHub and other providers can deliver webhooks. To keep Tembo on your network, make it internal:
On EKS Auto Mode, set scheme: internal in the IngressClassParams instead. On an internal network, uncheck Active on the GitHub App: comments that mention Tembo, issue and pull request triggers, and pull request status updates then don’t work.

​
Postgres and Redis

By default, the chart runs Postgres and Redis in your cluster. Agent hosts reach them through internal load balancers at postgres.<your-host> and redis.<your-host>; set postgresql.hostAccess.hostname or redis.hostAccess.hostname to use other names. For production, use managed services, such as Amazon RDS and ElastiCache, for backups and high availability:
  • Agent hosts connect to them directly. On AWS, add host_access_rules to the Terraform module for their security groups.
  • Each agent host holds about 50 database connections. Set the database’s max_connections to about 50 per host, plus 50.
  • If Redis needs a password, set redis.password under config.

​
Agent hosts

On AWS, the module’s Helm values create a host class and a pool, both named default. The pool keeps one host running, adds hosts when less than 32 GiB of memory is free, and runs up to three. To change it:
Set minHosts: 0 to run no hosts while Tembo is idle; the first session then waits for a host to start. See Agent hosts for how pools scale.

​
Instance types

Set the module’s instance_types. Agent hosts need nested virtualization, and must fit the largest sandbox size you use: its vCPUs plus 1, and its memory plus about 8 GiB.
  • Use local NVMe (the d in c8id). Hosts keep VM disks and snapshots on it; on EBS, stopping and forking sessions is much slower.
  • Use about 1 vCPU per 2 GiB. Pools add hosts based on memory, so hosts should run out of memory before CPU.
  • Use one processor generation, such as only c8id and m8id. Sessions resume from saved memory only on a matching CPU.

​
Warm VMs

For projects with Warm pool on, each host keeps up to 2 warm VMs per size, and 1 for large, xl and xxl. To change a size, or turn it off with 0:

​
Object storage

On AWS, the module creates an S3 bucket and sets objectStorage in its Helm values. To use a bucket you already have, set the module’s object_storage_bucket_name, and allow your Tembo URL in its CORS. Without object storage (object_storage_enabled = false), project builds and file uploads are off.

​
Integrations

  • GitHub: see GitHub.
  • Others, such as Slack or Linear: set their config keys under config, or keep them in Secrets listed under configSecrets.

​
Need Help?

If you run into any issues, contact support@tembo.io.