So I have quite a large Meteor.Settings file, and when I tried to load all the json in an AWS EBS, it does not allow the length to exceed 256 characters (and mine is a lot more). I read in https://blog.sunsama.com/meteor-docker-opsworks/ that they used NPM.require to load the settings.json file into the METEOR_SETTINGS Environment variable. Can someone guide me as to how to do this?
1 Like
process.env.METEOR_SETTINGS = readSettingsFile().
Can you elaborate on this?
I tried this very approach with sikka and iron-router-ga and neither could pick up the settings.
Also, should it work for both run and build?
you probably want this code to be executed before any code of packages. getting this done would require various hacks to the compiled files.
But the original question was about using process.env object, as far as I can tell.
Ah yes! This needs to go before packages and it is not possible without a hack.
Hm, do you think it would be possible with a build plugin?
I’m thinking, register a build plugin that looks for a filename.settings file, take the content, validate the json and pass it on to process.env object?
Would that work both for meteor build and meteor run?
If it is something that would work, I guess @arjunrajjain can benefit from it as well.
It is just that I’m kind of hung up on and bummed out about meteor_settings nowadays.
@serkandurusoy I completely agree with you. Its definitely a pain when it comes to deployment and a package to dynamically load the settings.json file before other packages are executed would be a lot easier. I’m curious as to how/when @jkatzen loads the json file in Sunsama.
I have my settings stored in a JSON file that is on my host machine. From there, I have an environment variable that specifies the path to my JSON file, which I call METEOR_SETTINGS_PRODUCTION.
Once my file and environment variable are setup, I load the settings into by having a Meteor.startup function within my server/lib/config.js file. Here’s an example of how that file looks:
Meteor.startup(function() {
// This will setup meteor settings from a file on the server
Meteor.settings = Npm.require(process.env.METEOR_SETTINGS_PRODUCTION);
// If you have public settings that need to be exposed to the client,
// you can set them like this
if (Meteor.settings && Meteor.settings.public) {
__meteor_runtime_config__.PUBLIC_SETTINGS = Meteor.settings.public;
}
});
2 Likes
Awesome! When you deploy your app using docker + opswork, how do you know the path of the settings.json file?
In your dockerfile, you can use the COPY or ADD directive.
1 Like
is there a specific filepath that I should be using for the container’s settings.json…or can i simply do the following :
COPY ./settings.json ./settings.json
and have the METEOR_SETTINGS_PRODUCTION Environment Variable set to “./settings.json”
Does this also get picked up by packages that require settings?
EDIT:
Nope, it does not! 
@arjunrajjain - You can use whatever filepath you want. For my setup, I opted to put it into a folder I knew and which didn’t have a long pathname and have set that env variable to the full path.
@serkandurusoy - You’re right - most packages will have environment variables or some way to initiate them with some js startup code. After loading in my settings, I initialize such packages this way either with their documented code or by looking at how the packages load themselves. For dev, you can do something as simply as meteor --settings=$METEOR_SETTINGS_ENV_VARIABLE.
…for those confused as to why the length of an environment variable would matter to your EBS-backed ec2 instances; it doesn’t. OP is talking about Elastic Beanstalk, Amazon’s free deployment and configuration service (which apparently has a 200-character limit on environment variables). Not ec2’s Elastic Block Store. 
Do we have an evolved way to set Meteor.settings ourselves ( like the @jkatzen solution, but factoring in the @serkandurusoy caveat above ) since 2015?
Handing variables between environments and obeying external control seems like a big hoop to jump through to give up major freedom, not to be able to manually set a configuration object, and have the values persist wherever else imported.
Especially using docker ( specifically implementing meteor-base ) this issue has burned a lot of time and removes confidence in the values propagating properly across environments.
[ The workaround there trailed off in 2020, but seems to draw attention to underlying issue of not being able to set Meteor.settings object from within code without environment variables: Add `--settings` Support to Package` · Issue #166 · disney/meteor-base · GitHub ]
As we near the 10-year anniversary of this topic ( and the link referenced in original post is no longer online ) I thought I’d ask 
[ Key desire/requirement: Ability to pull/set Meteor.settings configuration from within code without using environment variables at all. Would treat current behavior as default unless already defined or similar. ]