> For the complete documentation index, see [llms.txt](https://docs.apica.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.apica.io/getting-started/paas-deployment/deploying-with-external-postgres-and-redis.md).

# Deploying with external Postgres and Redis

For deployments that wish to utilize external services for the PostgreSQL and/or Redis functions, instead of the built-in components.

## Configure Helm Values

To utilize external database and/or cache services in the cloud, configure the following   [Helm values](/getting-started/paas-deployment.md#prepare-your-values-file) as needed.

```
global:
  environment:
    redis_host: "<your-cache-service-connection-host>"
    redis_tls:
      enabled: true
      skip_verify: false
    postgres_host: "<your-database-service-connection-host>"
    postgres_tls:
      enabled: true
      sslmode: "verify-full"
      mtls: false   # Set to true to require client certificate
  chart:
    postgres: false
    redis: false
  cnpg:
    enabled: false
```

If either the Postgres or Redis service TLS certificates are not automatically trusted by the host operating system, you can provide CA certificates via a Secret (see below). These will be mounted into the necessary pods and referenced by Ascent to trust the external services. You will also need to add a `tls` block to the following sections in your values file:

logiq-flash

```
  tls:
    certSecretName: "ascent-external-certs"  # or whatever your Secret is named
    postgres:
      caCert: "/flash/tls-certs/pg-ca.crt"  # omit for publicly-signed certs
      # mTLS gated by global.environment.postgres_tls.mtls
      clientCert: "/flash/tls-certs/pg-client.crt"  # mTLS client cert
      clientKey: "/flash/tls-certs/pg-client.key"   # mTLS client key
    redis:
      caCert: "/flash/tls-certs/redis-ca.crt"  # omit for publicly-signed certs      
```

flash-discovery

```
  tls:
    certSecretName: "ascent-external-certs"  # or whatever your Secret is named
    postgres:
      caCert: "/flash/tls-certs/pg-ca.crt"  # omit for publicly-signed certs
      # mTLS gated by global.environment.postgres_tls.mtls
      clientCert: "/flash/tls-certs/pg-client.crt"  # mTLS client cert
      clientKey: "/flash/tls-certs/pg-client.key"   # mTLS client key
```

flash-coffee

```
  tls:
    certSecretName: "ascent-external-certs"  # or whatever your Secret is named
    postgres:
      caCert: "/coffee/certs/pg-ca.crt"  # omit for publicly-signed certs
      # mTLS gated by global.environment.postgres_tls.mtls
      clientCert: "/coffee/certs/pg-client.crt"  # mTLS client cert
      clientKey: "/coffee/certs/pg-client.key"   # mTLS client key
    redis:
      caCert: "/coffee/certs/redis-ca.crt"  # omit for publicly-signed certs
```

## Create TLS Secret

If you need to provide CA or client certificates for Postgres and/or Redis, create a Kubernetes Secret of type `generic` with any of the following keys.

* `pg-ca.crt` - The certificate that issued the database server certificate. Required if the issuer is not in the host operating system's trust store. For example, Amazon provides a certificate bundle (`global-bundle.pem`) when creating a new RDS cluster. That file's contents would be the value of this key.
* `pg-client.crt` - The client certificate to be used to authenticate to the Postgres service. Required if `global.environment.postgres_tls.mtls` is set to `true`.
* `pg-client.key` - The client key to be used to authenticate to the Postgres service. Required if `global.environment.postgres_tls.mtls` is set to `true`.
* `redis-ca.crt` - The certificate that issued the Redis server certificate. Required if the issuer is not in the host operating system's trust store.

For example, to create the secret with the Amazon RDS bundle downloaded to the current directory:

```
kubectl create secret generic ascent-external-certs \
  --from-file=pg-ca.crt=./global-bundle.pem
```

If you are not sure whether your service endpoints are trusted by the OS or not, you can test on the host OS with the OpenSSL CLI:

```
openssl s_client -connect host:port </dev/null
```

If the server certificate is trusted, you will see a message like this near the end of the output:

```
Verify return code: 0 (ok)
```

If the certificate is not trusted, you will see a message like this:

```
Verify return code: 20 (unable to get local issuer certificate)
```