Specifically, asking about POSTGRES_CUSTOM_SSL_CERT_ALTNAME_REGEX env var, but i couldn't add it in the title due to title constraints.
In setting up Self hosted retool, (i'm running as a container in GCP Cloud Run) I encountered an issue getting the installation to talk to my Postgres DB in GCP CloudSQL (its a private only instance)
The issue specifically was validating the certificates. (Error: Hostname/IP does not match certificate's altnames:) The problem is that the certificates issued by cloud sql, changed a while back and now they don't include the instance name making it near imposible to properly validate them. See this thread for more details: pg with google cloud postgres · Issue #79 · brianc/node-postgres-docs · GitHub
I came across an undocumented env var POSTGRES_CUSTOM_SSL_CERT_ALTNAME_REGEX, that i took a guess at configuring based on the name (REGEX lol) I set its value to .* and now the ssl validation is succeeding. I'd like to know if there is
a) a better way to achieve this
b) documentation on what the var does, so i can attempt to set something more specific that a wildcard
"The name of the custom SSL certificate file to use. This is required when configuring Google Cloud SQL as the database to use instead of Retool's PostgreSQL database."
I have not deployed Retool with GCP, or used the specific variable you shared yet, but I hope this doc helps you find some answers.
Thanks Paulo. POSTGRES_CUSTOM_SSL_CERT_FILE_NAME appears to be referring to the name of the certificate file on the file system. Not the hostname of the Postgres instance inside the certificate. (at least, thats how I am using it, and it is working when set to a file name)
it seems there is a whole collection of undocumented environemtn variables - at least some of which are reasonably important (listed at: https://www.retool.monster/ )
Well thats unfortunate it appears the site has been taken down - shame it was a great resource (even though it contained no details about what the variables did)
Thanks for flagging! Our docs have the most widely used & up-to-date environment variables, but there may be some that aren't well documented if they are not broadly recommended or are very specific to a certain feature. I can put in a feature request to document "legacy" environment variables that are very niche or are no longer needed