Setting environment variables / configuration settings in managed postgres

Hey Eddie,

When using DigitalOcean’s Managed PostgreSQL service, you’re working within a managed environment that doesn’t provide direct access to the underlying server configuration, including the ability to set environment variables in the traditional way (like you would on a local PostgreSQL installation). This limitation is primarily for security and stability reasons, as the service is designed to abstract away many of the server management details.

The best thing to do to get your voice heard regarding this would be to head over to our Product Ideas board and post a new idea, including as much information as possible for what you’d like to see implemented.

https://ideas.digitalocean.com/

However, here are some alternative approaches you can consider:

1. Encrypted Configuration Table

While storing keys directly in the database is not ideal, you can create a dedicated configuration table with encrypted values. This method allows you to use PostgreSQL’s built-in encryption functions to secure the keys. Your functions can then decrypt these values at runtime.

• Pros: Easy to implement and manage within the existing database system.
• Cons: Adds complexity to your functions; cryptographic operations have to be managed within PostgreSQL.

2. External Secrets Manager

Utilize an external secrets management service like the DigitalOcean’s App Platform environment variables (if your application is hosted on the App Platform).

Your application retrieves the necessary keys from the App Platform secrets manager and then passes them to the PostgreSQL functions as parameters.

• Pros: Highly secure, centralized management of secrets for both your app and database, industry-standard practices.
• Cons: Requires integration with the App Platform, and potentially minor modifications to how your functions are invoked.

3. Application-Level Management

Handle the cryptographic operations within your application code rather than in PostgreSQL functions. This way, you can leverage your application’s existing environment variables or configuration files to manage the keys.

• Pros: Keeps cryptographic operations within the application layer, which might be more secure and manageable.
• Cons: Moves complexity and processing out of the database, which may or may not be desirable based on your application architecture.

Each of these approaches has its trade-offs. The best solution depends on your application architecture, security requirements, and operational preferences. Unfortunately, due to the managed nature of DigitalOcean’s PostgreSQL offering, there’s no direct way to set environment variables as you would in a self-managed PostgreSQL setup where you have full access to the server.

Hope that helps!

- Bobby.