> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tembo.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Configuration

> Change the defaults of Tembo on Kubernetes.

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:

```bash theme={null}
helm upgrade tembo ./tembo-<version>.tgz -n tembo -f tembo-aws.json -f values.yaml
```

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:

```bash theme={null}
kubectl -n tembo annotate tembohost <host> hosts.tembo.io/force-terminate=true
kubectl -n tembo delete tembohost <host> --wait=false
```

> [!WARNING]
>
> 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:

```yaml theme={null}
license:
  existingSecret: tembo-license
  key: licenseKey
```

## 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:

```yaml theme={null}
ingress:
  annotations:
    alb.ingress.kubernetes.io/scheme: 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:

```yaml theme={null}
postgresql:
  enabled: false
  external:
    # A Secret in the namespace with a DATABASE_URL key.
    existingSecret: tembo-database
redis:
  enabled: false
  external:
    host: <your-redis-host>
    port: 6379
```

* 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:

```yaml theme={null}
compute:
  hostPools:
    default:
      minHosts: 1
      maxHosts: 5
      minIdleMemory: 32Gi
```

Set `minHosts: 0` to run no hosts while Tembo is idle; the first session then waits for a host to start. See [Agent hosts](https://docs.tembo.io/features/self-hosted/kubernetes/agent-hosts.md) for how pools scale.

### Instance types

Set the module's `instance_types`. Agent hosts need nested virtualization, and must fit the largest [sandbox size](https://docs.tembo.io/features/sandbox/overview.md#sandbox-sizes) you use: its vCPUs plus 1, and its memory plus about 8 GiB.

| Largest size | Instance type |
| - | - |
| `xl` or smaller | `c8id.8xlarge` (32 vCPU, 64 GiB), the default |
| `xxl` | `c8id.12xlarge` (48 vCPU, 96 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:

```yaml theme={null}
compute:
  hosts:
    config:
      sandbox.warmPool.micro: 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](https://docs.tembo.io/features/self-hosted/integrations/github.md).
* **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](mailto:support@tembo.io).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.