Let's say my application connects to my database. This requires me to have the username and database in my config as follows:


I have an automated deployment to set this up and I don't want to store the database both in the application and my deployment script. Therefore my options as I see them are:

  • Make it so postgresql isn't secured with a password and secure another way
  • Make the deployment script generate a random pass and have it add it to both postgresl and the configuration file

Can anyone help me understand how they would approach this from a security point of view please.

2 Answers 2


This actually sounds like a pretty decent use case for PostgreSQL's TLS support. You can configure a trusted client certificate for the application to use with your deployment script and then get the other advantages of not having a shared secret, plus obviously encryption too (unless your app is already CPU bound, in which case selecting the NULL cipher is a possible workaround). Sometimes adding TLS complicates matters, but it sounds like in this case it might actually simplify them.


TLS session bring-up can add a few milliseconds of latency, but if you're already managing a connection pool, I don't suspect the app would notice.


Postgres allows you to have certain users to connect from a particular IP without providing a password. This can be done using in the pg_hba.conf file using the following format:

host       database  user  address  auth-method  [auth-options]

(Taken from Postgres' documentation)

Another alternative, and perhaps a more secure one, would be to use environment variables (assuming you're on a Linux-alike system):

(from your shell, which can be loaded in a .profile or .login file):

export DB_USER='scott'
export DB_PASS='tiger'

And then in your script, you could simply do:


or ENV['DB_USER'], $_ENV['DB_USER'], depending on the language you use.

This allows you to "share" your code, without having any sensitive information exposed. It may even help you to put your DB hostname and DB name into variables.

  • Of course, anyone who can claim that IP addr or intercept its traffic can also now connect without a password, too.
    – atk
    Mar 31, 2014 at 3:47
  • I was merely talking about the stored passwords, as the question indicated. I should've added encryption for data in transit, but didn't think that was the question.
    – ndrix
    Mar 31, 2014 at 5:32
  • 1
    Given that the question was "How to do automated deploys without storing database password in my software?", this was a good answer. Not sure why the downvote, but here's an upvote.
    – Brandon
    Aug 4, 2014 at 15:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .