Comments (7)
+1 heroku config:push
only supports a single .env
file. Would be great to have something similar for Dotenv that observes environmental specific files:
dotenv heroku:push --staging
from dotenv.
+1
from dotenv.
It seems like a task like that would encourage you to put production variables in your local .env
. My philosophy is that all the settings in your local .env
should be development-only. The server is really the only thing that should know the production credentials.
from dotenv.
@bkeepers production credentials could be manually uploaded to the server and copied into the app using deployment recipe, would this case still adhere to your philosophy? If not could you please clarify what are the advantages of dotenv vs, say, SettingsLogic approach?
from dotenv.
I'm pretty much against anything that encourages you to store production credentials in the repository.
If not could you please clarify what are the advantages of dotenv vs, say, SettingsLogic approach?
dotenv is really just meant as a development shim for apps that conform to twelve factor principles for config like Heroku. It does not attempt to solve any of the of the application concerns that SettingsLogic or Figaro try to solve.
from dotenv.
I think we're talking at cross-purposes. There is a difference between pushing an .env
file to a repo and pushing the adding the variables it contains to Heroku. Using $ heroku config:push
adds all the variables from a .env
file to the Heroku server - equivalent to calling $heroku config:add SOME_VAR=123
for each variable.
Environmental variables can generally be split into 2 sets: Application configuration shared across development/production/staging - configuration that is shared across environments such as TZ=Europe/London
and environmental configuration that is specific to a particular server/environment.
It seems to me that a mechanism for keeping the former in sync between environments can only be a good thing. Dotenv already supports sharing envs between environments using a base .env
file, so why not support keeping environments in sync by making it easy to push the variables to production or staging. Rather than encouraging people to upload envs it removes the need for it.
The second group are more debatable. Personally I find it very useful to have a single location where all my envs are stored. Obviously they aren't under source control, but it the advantage is that it greatly reduces the chances of what I think are the envs on staging or production and what I know are the envs. I currently add envs to production/staging as part of deployment, but I think it would be useful and within Dotenv's remit to offer a simple way to push the envs themselves.
from dotenv.
Having a command like this would certainly be cool. I understand that there are some legitimate uses as @1ndivisible describes, but it also could encourage people to store production creds in .env
. For now, I don't think the benefits outweigh the costs.
I would encourage someone to create a dotenv-heroku
gem that has this functionality.
from dotenv.
Related Issues (20)
- Just HOT 1
- Special characters are being escaped from the value of the environment variables HOT 3
- dotenv-rails loads dev environment when running system tests with Rails 7 HOT 5
- `Dotenv.load` call causes Rails app to be loaded twice HOT 2
- Not specifying required ruby version on Gemfile causes my bundler with ruby 2.5.x pull dotenv 2.8.0 HOT 6
- template is not created in working directory HOT 2
- Question on Removal of ### What other .env* files can I use? FAQ HOT 1
- README should explicitly call out the gem needed is `dotenv-rails` HOT 4
- environment specific env not loaded when using require: 'dotenv/load' HOT 1
- Rails < v6.1: LocalJumpError in tagged logging HOT 2
- autorestore: can't modify frozen Hash HOT 7
- Use existing TaggedLogger instead of re-wrapping it with `TaggedLogging` HOT 4
- Ruby warning: circular require considered harmful HOT 2
- v3.0.3 causes regression with semantic-logger v4.15.0 HOT 2
- [BUG] All logs are tagged with "dotenv" HOT 1
- Dotenv's tagged method conflicts with SemanticLogger's HOT 1
- loading multiple files are not correctly overwriting env variables HOT 1
- ActiveSupport::TestCase teardown error: undefined method `keys' for nil HOT 3
- Use ERB in env file? HOT 3
- Arbitrary code execution vulnerability (or intended behavior?)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dotenv.