Self-hosted: Getting no encryption error while start supabase helm chart even with 'DB_SSL=true', tenant migrations fail against Postgres that requires TLS (RDS) #52381
Environment
What happensStartup migrations for Querying the seeded row shows the cause: ExpectedWith Questions
Logs
Custom Values examplesecret: persistence: ingress: environment: |
Replies: 3 comments
|
no, the seed also deletes and recreates the tenant matching for the tenant you've already created, i'd set for metadata, if your chart matches current main, use |
|
Thanks, @nicholas-greenwood, for explaining the metadata and tenant connection behavior. Building on your answer, I’ve grouped the configuration details around the four questions above, including the Helm setup. 1. Does DB_SSL configure the seeded tenant?In These are separate connection configurations, even when they connect to the same RDS instance. That explains why Starting with v2.137.0, the seed reads For this startup error, I would first test a compatible release containing that change in staging, keeping 2. Are tenant settings overwritten on startup?Yes, when using the standard entrypoint with The seed deletes and recreates the tenant matching 3. How should the AWS CA bundle be configured?For the metadata connection, configure:
For tenant connections, That behavior also remains in the inspected 4. Which Helm values should be used for RDS?For chart
The inspected chart defaults to For example, this fragment mounts the CA bundle: deployment:
db:
enabled: false
realtime:
volumes:
- name: rds-ca
configMap:
name: rds-ca
volumeMounts:
- name: rds-ca
mountPath: /etc/rds
readOnly: trueThis assumes a ConfigMap named In your existing - name: DB_SSL
value: "true"
- name: DB_SSL_CA_CERT
value: /etc/rds/global-bundle.pemPreserve the other environment entries, including your database user and Keep your existing settings that disable the other Supabase components. Setting only When referencing existing Secrets, ensure ValidationAfter upgrading, check that:
The last check confirms encryption, not certificate verification by the client. Could you share your exact chart version and confirm whether certificate verification is required for tenant connections as well? That would help narrow down the remaining configuration. |
Thanks, @nicholas-greenwood, for explaining the metadata and tenant connection behavior. Building on your answer, I’ve grouped the configuration details around the four questions above, including the Helm setup.
1. Does DB_SSL configure the seeded tenant?
In
v2.102.3,DB_SSLconfigures Realtime’s metadata database connection, while the self-hosted seed explicitly sets the tenant extension’sssl_enforcedtofalse.These are separate connection configurations, even when they connect to the same RDS instance. That explains why
_realtimemigrations succeed but tenant migrations fail withno encryption: the tenant connection is attempting to connect without TLS.Starting with v2.137.0, the see…