Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
Hi everyone!
I'm using Stripe, PayPal, Google RECAPTCHA and stuff like that which requires public and private keys. I'm currently storing them in my .env file as STRIPE_KEY=, STRIPE_PRIVATE_KEY= ...... But I got to a point where I realized that these keys might actually have to be managed in some way without accessing the .env file. Which is actually the better solution - retrieve these keys from the .env file or from the database? Also what type of data is preferred to store inside the .env file? And is it safe to actually retrieve data from the .env file with the function env()? Is the .env file editable without actually accessing the file? For example I want to edit the STRIPE_KEY without accessing the file, can I do something like
editenv('STRIPE_KEY', 'SOME VALUE');
No you cannot edit it like that. And actually you cannot use env() in production after you have cached the application. What you do is to use env() inside of config files. You can then overwrite config() at runtime if needed config(['stripe.key' => 'somevalue'])
https://laravel.com/docs/8.x/configuration#accessing-configuration-values
But .env is the location where you save all environment related data. This also means api keys and similar.
Always store your secret/APIs keys in the .env file. And yes, it's safe to store your Environment variables there. I would suggest that you retrieve your keys from a config file that reads from the .env, and there you can add your condition and decide which key you want to get. The Environment variables should not be editable by your application.
Well, I still can't get it how I'll be able to change these values without accessing the files even if I store them in the config file.
you can store some things in the database if you prefer. This would be especially true if the keys are per user.
Okay, I've understand that they must go in the .env file and read them through config file which is getting the value of the .env file. But how do I actually edit them without direct access to the files?
@01101100 01100001 01110 Why dont you have access to the .env file?
@Sinnbeck Of course, I currently have access to the file. The problem is that the client for whom the application is requested to be able to edit these things at any time (i.e. from the admin panel).
@01101100 01100001 01110 What a very weird request. But then you will need to save them in a location they can edit. So even though best practice is .env, they are forcing you to move it to the database.
@Sinnbeck Yeah, the customer is kinda weird. I've already built the table and I'm storing them right now in the database (but the app is still getting the values from the .env file in order to work). What should be my next step?
@01101100 01100001 01110 You can inject them into config, like I have shown you above.
config(['cashier.key' => $keyFromDatabase])
@Sinnbeck But wait a second, why do I store them in the database when I can overwrite the config file?
@01101100 01100001 01110 Where else would you store them? And you dont overwrite the config file. Just the config value
@01101100 01100001 01110 your config should be from your source repository
suppose you deploy new code, now you have trampled on the customers keys and their site no longer works. Worse, this might affect something totally unrelated to the reason you deployed
@01101100 01100001 01110 How do you mean override the config file? You can only override it for one request, then the next request pull the data from the cached env file or the DB, if you have it working that way, again
Or I can literally just store these keys always in the database (nowhere else) and retrieve them where necessary. This way I have nothing to do with config and env files. That's the easiest solution by my understandings.
@01101100 01100001 01110 Unless you are using a package that is specifically reading the values from config, and does not have a way of manually setting the keys.. You said this yourself
I'm storing them right now in the database (but the app is still getting the values from the .env file in order to work).
@01101100 01100001 01110 it depends if you have control over the service privider class that uses those credentials.
If you are using a third party provider it may ONLY use config. note that I am not referring to the config files but to the config that it's loaded into memory
Well, as soon as Stripe has the following command:
\Stripe\Stripe::setApiKey(KEY);
where I can actually set manually the secret key I will have no problems with it. But I'm not quite sure for PayPal... In general the main payment provider I use is Stripe. I haven't built the subscriptions with PayPal yet. And my app can't work at this point without subscription, so I think retrieving them from the database is a good solution at this point. Also not quite sure for Google RECAPTCHA...
Please or to participate in this conversation.