For a bit more context, this practice of the DATABASE_URL has been popularized by Heroku and things like the The Twelve-Factor App which are definitely interesting principles to follow in order to make apps serverless-ish :)
Regarding the CA cert, the problem is indeed a bit different, I'd grease up your setup a bit:
The CA cert can be explicitly committed to your code (it's not a secret), so I guess a ssl folder at the root of the project would be more fitting than putting into storage
You can probably just ask for the file name as an environment variable, like DB_CERT=do would translate into something like __dir__ . "/../ssl/$certName.crt" (pardon my rusty PHP it's been time)
very much, thanks for the clarification.
Are you sure the certificate can committed? It's used for connecting to the database, and when there are multiple environments, keeping its location as an environment variable seems like a better option.
The CA certificate is per project (as Digital Ocean calls them), so all DB's you create within the same Digital Ocean project share the same CA certificate, or at least for the same database type. All my MySQL databases in the same project use the same CA certificate.
It's safe to commit since it's just a public certificate, no private data in there. Since it's just the public part there is no worry in anyone using it for something bad since that would require the private part of the CA certificate which you are not given it's just there to validate you are talking to the correct database server without Digital Ocean needing to use a publicly signed certificate for it that is already trusted by your host machine (which has a library of trusted CA certificates used to validate public certificates).
To make it easy on myself, I have this snippet in my config:
The actual path to the file being <project root>/resources/certs/do_mysql_ca.pem.
Added benefit of keeping it in git is that it's already shared with the rest of the team in case they need to connect to the database directly (although I keep the circle that can actually do that really small to prevent accidental "I was in the wrong database and deleted everything" calls).
wow thanks Alex for the super detailed description! It's all clear and makes perfect sense.
I would've been worried with those accidental situations of "oops I deleted production DB" that's why it was unclear that the CA certificate can actually be committed to the repo.
But it makes sense, thanks again!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks Rémy! I didn't notice that option! Looks like a nice one-liner to add those connection details 📡
However, I still think the CA certificate is required to be uploaded and configured, right?
For a bit more context, this practice of the
DATABASE_URL
has been popularized by Heroku and things like the The Twelve-Factor App which are definitely interesting principles to follow in order to make apps serverless-ish :)Regarding the CA cert, the problem is indeed a bit different, I'd grease up your setup a bit:
ssl
folder at the root of the project would be more fitting than putting into storageDB_CERT=do
would translate into something like__dir__ . "/../ssl/$certName.crt"
(pardon my rusty PHP it's been time)Hope this helps :)
very much, thanks for the clarification.
Are you sure the certificate can committed? It's used for connecting to the database, and when there are multiple environments, keeping its location as an environment variable seems like a better option.
The CA certificate is per project (as Digital Ocean calls them), so all DB's you create within the same Digital Ocean project share the same CA certificate, or at least for the same database type. All my MySQL databases in the same project use the same CA certificate.
It's safe to commit since it's just a public certificate, no private data in there. Since it's just the public part there is no worry in anyone using it for something bad since that would require the private part of the CA certificate which you are not given it's just there to validate you are talking to the correct database server without Digital Ocean needing to use a publicly signed certificate for it that is already trusted by your host machine (which has a library of trusted CA certificates used to validate public certificates).
To make it easy on myself, I have this snippet in my config:
This allows me to set this in my .env:
The actual path to the file being
<project root>/resources/certs/do_mysql_ca.pem
.Added benefit of keeping it in git is that it's already shared with the rest of the team in case they need to connect to the database directly (although I keep the circle that can actually do that really small to prevent accidental "I was in the wrong database and deleted everything" calls).
wow thanks Alex for the super detailed description! It's all clear and makes perfect sense.
I would've been worried with those accidental situations of "oops I deleted production DB" that's why it was unclear that the CA certificate can actually be committed to the repo.
But it makes sense, thanks again!