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

# Networking

> What the Tembo chart exposes, what you set up so people and agent hosts can reach it, and the EKS and GKE setups we use.

The chart creates the Kubernetes resources that expose Tembo. Your cluster's controllers turn them into load balancers, DNS records and certificates.

***

## What the chart creates

With `ingress.host: tembo.example.com`:

| Resource | Name | Serves | Who connects |
| - | - | - | - |
| Ingress `tembo` | `tembo.example.com` | The web app and API | Users and webhooks |
| Ingress `tembo-previews` | `*.previews.tembo.example.com` | Computer previews and `tembo service` URLs | Users' browsers |
| Service `tembo-sandbar-hosts` (internal load balancer) | `sandbar.tembo.example.com` | Preview tunnels | Agent hosts |
| Services `tembo-postgresql-hosts` and `tembo-redis-hosts` (internal load balancers) | `postgres.tembo.example.com`, `redis.tembo.example.com` | The bundled Postgres and Redis | Agent hosts |

* The internal Services carry their DNS name in an `external-dns.kubernetes.io/hostname` annotation.
* The Postgres and Redis Services exist only with the bundled data stores and `compute.mode: controller`.
* Previews are on by default from chart 0.6.0, with Tembo releases later than 0.2.892. To turn them off, set `sandbar.enabled: false`.

***

## What you set up

### 1. An Ingress controller

It turns both Ingresses into load balancers, so users and webhooks can reach Tembo. Set `ingress.className` and any `ingress.annotations` your controller needs. The previews' Ingress gets the same ones.

On AWS or GKE, turn on `ingress.aws` or `ingress.gcp` instead of writing annotations. Both take the same settings, and the chart turns them into that cloud's configuration:

| Setting | What it does |
| - | - |
| `internal` | An internal load balancer, reachable only on your network |
| `redirectToHttps` | Redirects HTTP to HTTPS (on by default) |
| `timeoutSeconds` | How long requests and websockets can stay open (default 3600) |
| `certificates` | Your certificates: ACM ARNs on AWS, pre-shared certificate names on GKE. Empty uses the cloud's own. |

### 2. DNS

Every name in the table must resolve to its load balancer: browsers find Tembo by name, and agent hosts find Sandbar, Postgres and Redis by name.

* **With [external-dns](https://github.com/kubernetes-sigs/external-dns):** it reads the Ingresses' hosts and the Services' annotations and creates the records.
* **Without it:** create the records yourself once the load balancers exist (`kubectl -n tembo get ingress,svc`).

The internal names only need to resolve from your VPC.

### 3. TLS certificates

Tembo is served over HTTPS, so you need two certificates:

* `tembo.example.com`
* `*.previews.tembo.example.com`. A `*.example.com` certificate doesn't cover it.

Your load balancer can provide them (for example ACM on AWS). Otherwise, [cert-manager](https://cert-manager.io) can issue them into Secrets:

* Name the app's Secret in `ingress.tls.secretName`. The previews' Secret is always `tembo-previews-tls`. On GKE, only previews need one.
* Add a `cert-manager.io/cluster-issuer` annotation to `ingress.annotations`.
* Wildcards need a ClusterIssuer that uses DNS-01.

If the previews certificate is missing, only previews fail. The web app and API keep working.

***

## Examples

`ingress.aws` and `ingress.gcp` need a chart released after 0.6.0. Before it, GKE used `ingress.gke.enabled`.

### EKS

We use the AWS Load Balancer Controller (EKS Auto Mode), external-dns and ACM.

```yaml theme={null}
ingress:
  className: alb
  host: tembo.example.com
  aws:
    enabled: true
```

* **Load balancers:** `ingress.aws` makes each Ingress an internet-facing ALB with an HTTPS redirect, and sets its health checks. On EKS Auto Mode, internal load balancers need the `eks.amazonaws.com/nlb` class. The module's Helm values set it for Postgres and Redis, and Sandbar uses the same one.
* **Certificates:** request ACM certificates for `tembo.example.com` and `*.previews.tembo.example.com` in the cluster's region. The ALB finds them by name, or list their ARNs in `ingress.aws.certificates`. It can't use Kubernetes Secrets, so cert-manager doesn't apply here.

### GKE

We use GKE's built-in Ingress, external-dns and cert-manager, with a Let's Encrypt ClusterIssuer that solves [DNS-01 in Cloud DNS](https://cert-manager.io/docs/configuration/acme/dns01/google/).

```yaml theme={null}
ingress:
  host: tembo.example.com
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
  gcp:
    enabled: true
```

* **Load balancers:** `ingress.gcp` sets up both Ingresses for GKE, with health checks and the HTTPS redirect. To serve on a reserved IP, add a `kubernetes.io/ingress.global-static-ip-name` annotation.
* **Certificates:** GKE gives `tembo.example.com` a Google-managed certificate. Those can't be wildcards, so cert-manager issues `*.previews.tembo.example.com` into `tembo-previews-tls`. Use your ClusterIssuer's name in the annotation.

***

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