Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
114 changes: 110 additions & 4 deletions src/langsmith/self-host-external-postgres.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ title: Connect to an external PostgreSQL database
sidebarTitle: Connect to an external PostgreSQL database
---

LangSmith uses a PostgreSQL database as the primary data store for transactional workloads and operational data (almost everything besides runs). By default, LangSmith Self-Hosted will use an internal PostgreSQL database. However, you can configure LangSmith to use an external PostgreSQL database (). By configuring an external PostgreSQL database, you can more easily manage backups, scaling, and other operational tasks for your database.
LangSmith uses a PostgreSQL database as the primary data store for transactional workloads and operational data (almost everything besides runs). By default, LangSmith Self-Hosted will use an internal PostgreSQL database. However, you can configure LangSmith to use an external PostgreSQL database. By configuring an external PostgreSQL database, you can more easily manage backups, scaling, and other operational tasks for your database.

## Requirements

Expand All @@ -17,13 +17,13 @@ LangSmith uses a PostgreSQL database as the primary data store for transactional

* A user with admin access to the PostgreSQL database. This user will be used to create the necessary tables, indexes, and schemas.

* This user will also need to have the ability to create extensions in the database. We use/will try to install the btree\_gin, btree\_gist, pgcrypto, citext, ltree, and pg\_trgm extensions.
* This user will also need to have the ability to create extensions in the database. We use/will try to install the `btree_gin`, `btree_gist`, `pgcrypto`, `citext`, `ltree`, and `pg_trgm` extensions.

* If using a schema other than public, ensure that you do not have any other schemas with the extensions enabled, or you must include that in your search path.

* Support for pgbouncer and other connection poolers is community-based. Community members have reported that pgbouncer has worked with `pool_mode` = `session` and a suitable setting for `ignore_startup_parameters` (as of writing, `search_path` and `lock_timeout` need to be ignored). Care is needed to avoid polluting connection pools; some level of PostgreSQL expertise is advisable. LangChain Inc currently does not have roadmap plans for formal test coverage or commercial support of pgbouncer or amazon rds proxy or any other poolers, but the community is welcome to discuss and collaborate on support through GitHub issues.

* By default, we recommend an instance with at least 2 vCPUs and 8GB of memory. However, the actual requirements will depend on your workload and the number of users you have. We recommend monitoring your PostgreSQL instance and scaling up as needed.
* By default, we recommend an instance with **at least 2 vCPUs and 8GB of memory**. However, the actual requirements will depend on your workload and the number of users you have. We recommend monitoring your PostgreSQL instance and scaling up as needed.

## Connection String

Expand All @@ -33,7 +33,7 @@ You will need to provide a connection string to your PostgreSQL database. This c
* Port
* Database
* Username
* Password(Make sure to url encode this if there are any special characters)
* Password (Make sure to url encode this if there are any special characters)
* URL params

This will take the form of:
Expand Down Expand Up @@ -75,3 +75,109 @@ POSTGRES_DATABASE_URI="Your connection url"
</CodeGroup>

Once configured, you should be able to reinstall your LangSmith instance. If everything is configured correctly, your LangSmith instance should now be using your external PostgreSQL database.

## TLS with PostgreSQL

Use this section to configure TLS for PostgreSQL connections. For mounting internal/public CAs so LangSmith trusts your PostgreSQL server certificate, see [Configure custom TLS certificates](/langsmith/self-host-custom-tls-certificates#mount-internal-cas-for-tls).

### Server TLS (one-way)

To validate the PostgreSQL server certificate:

- Provide a CA bundle using `config.customCa.secretName` and `config.customCa.secretKey`.
- Use `sslmode=require` or `sslmode=verify-full`, as well as `sslrootcert=system` to your connection URL.

<Warning>
Mount a custom CA only when your PostgreSQL server uses an internal or private CA. Publicly trusted CAs do not require this configuration.
</Warning>

<CodeGroup>

```yaml Helm (server TLS)
config:
customCa:
secretName: "langsmith-custom-ca" # Secret containing your CA bundle
secretKey: "ca.crt" # Key in the Secret with the CA bundle
postgres:
external:
enabled: true
connectionUrl: "myuser:mypassword@myhost:5432/mydatabase?sslmode=verify-full&sslrootcert=system"
customTls: true
```

```yaml Kubernetes Secret (CA bundle)
apiVersion: v1
kind: Secret
metadata:
name: langsmith-custom-ca
type: Opaque
stringData:
ca.crt: |
-----BEGIN CERTIFICATE-----
<ROOT_OR_INTERMEDIATE_CA_CERT_CHAIN>
-----END CERTIFICATE-----
```

</CodeGroup>

### Mutual TLS with Client Auth (mTLS)

As of LangSmith helm chart version **0.12.28**, we support mTLS for PostgreSQL clients. For server-side authentication in mTLS, use the [Server TLS steps](#server-tls-one-way) (custom CA) in addition to the following client certificate configuration.

If your PostgreSQL server requires client certificate authentication:

- Provide a Secret with your client certificate and key.
- Reference it via `postgres.external.clientCert.secretName` and specify the keys with `certSecretKey` and `keySecretKey`.
- Use `sslmode=verify-full` and `sslrootcert=system` in your connection URL.

<CodeGroup>

```yaml Helm (client Auth)
postgres:
external:
enabled: true
connectionUrl: "myuser:mypassword@myhost:5432/mydatabase?sslmode=verify-full&sslrootcert=system"
customTls: true
clientCert:
secretName: "postgres-mtls-secret"
certSecretKey: "tls.crt"
keySecretKey: "tls.key"
```

```yaml Kubernetes Secret (client cert/key)
apiVersion: v1
kind: Secret
metadata:
name: postgres-mtls-secret
type: Opaque
stringData:
tls.crt: |
-----BEGIN CERTIFICATE-----
<CLIENT_CERT>
-----END CERTIFICATE-----
tls.key: |
-----BEGIN PRIVATE KEY-----
<CLIENT_KEY>
-----END PRIVATE KEY-----
```

</CodeGroup>

#### Pod security context for certificate volumes

The certificate volumes mounted for mTLS are protected by file access restrictions. To ensure all LangSmith pods can read the certificate files, you must set `fsGroup: 1000` in the pod security context.

You can configure this in one of two ways:

**Option 1: Use `commonPodSecurityContext`**

Set the `fsGroup` at the top level to apply it to all pods:

```yaml
commonPodSecurityContext:
fsGroup: 1000
```

**Option 2: Add to individual pod security contexts**

If you need more granular control, add the `fsGroup` to each pod's security context individually. See the [mTLS configuration example](https://github.com/langchain-ai/helm/blob/main/charts/langsmith/examples/mtls_config.yaml) for a complete reference.
29 changes: 24 additions & 5 deletions src/langsmith/self-host-external-redis.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -252,7 +252,7 @@ stringData:

### Mutual TLS with Client Auth (mTLS)

As of LangSmith helm chart version **0.12.26**, we support mTLS for Redis clients. For server-side authentication in mTLS, use the Server TLS steps above (custom CA) in addition to the client certificate configuration below.
As of LangSmith helm chart version **0.12.28**, we support mTLS for Redis clients. For server-side authentication in mTLS, use the Server TLS steps above (custom CA) in addition to the client certificate configuration below.

If your Redis server requires client certificate authentication:

Expand All @@ -269,8 +269,8 @@ redis:
enabled: true
clientCert:
secretName: "redis-mtls-secret"
certSecretKey: "client.crt"
keySecretKey: "client.key"
certSecretKey: "tls.crt"
keySecretKey: "tls.key"
# Standalone example:
# connectionUrl: "rediss://host:6380/0?password=<PASSWORD>"
# Or, for Cluster:
Expand All @@ -291,14 +291,33 @@ metadata:
name: redis-mtls-secret
type: Opaque
stringData:
client.crt: |
tls.crt: |
-----BEGIN CERTIFICATE-----
<CLIENT_CERT>
-----END CERTIFICATE-----
client.key: |
tls.key: |
-----BEGIN PRIVATE KEY-----
<CLIENT_KEY>
-----END PRIVATE KEY-----
```

</CodeGroup>

#### Pod security context for certificate volumes

The certificate volumes mounted for mTLS are protected by file access restrictions. To ensure all LangSmith pods can read the certificate files, you must set `fsGroup: 1000` in the pod security context.

You can configure this in one of two ways:

**Option 1: Use `commonPodSecurityContext`**

Set the `fsGroup` at the top level to apply it to all pods:

```yaml
commonPodSecurityContext:
fsGroup: 1000
```

**Option 2: Add to individual pod security contexts**

If you need more granular control, add the `fsGroup` to each pod's security context individually. See the [mtls configuration example](https://github.com/langchain-ai/helm/blob/main/charts/langsmith/examples/mtls_config.yaml) for a complete reference.