Envaroments in meteor

This might be a bit of noob question but how do I separate environments in meteor?

I come from rails and there I have env folders in config folder allowing me for different settings for asset build, DB location and password rules etc, for dev, test and prod environments.

I can also separate gem installs in my GEMFILE based the environment. For example I can say

ryby 2.3.0

gem 'pg’
gem 'puma’
gem ‘sass’

group :development, :test do
gem 'better-errors’
gem 'rspec’

This is will use ruby version 2.3.0 installs postgress, puma webserver and sass to all envaroments but better errors and rspec testing only for test and dev.

How do similar thing in Meteor there are some packages and npm that I would like to run in test and dev only?

The environment is set using the computer’s environment variables and the most commonly accepted (which is also made popular by the earlier nodejs frameworks) convention is to set

NODE_ENV = production

and in your meteor code - on the server -


will return whatever you have set on that computer/user environment variables for NODE_ENV.

Again by convention, you do not set these from your application or application configurations. For the app, it is better be a read only value.

To separate testing/staging/development/thebeach/mamascouch environments, you can set them accordingly on each.

Now, where and how you will use this information is again up to you.

Since you can get the value of this from within your server code, you can pretty much do whatever you want with it.

Unlike rails, meteor cli is not that tightly integrating with your devlopment workflow, so don’t expect to run meteor commands and see environment-based output. Again, you handle that within your app code, wether it is the tests, or the app itself.

Mind you, though, some PaaS nodejs hosting providers do set this to “production” by default.

Here’s a quick reference of some environment variables that meteor is aware of out of the box: http://www.meteorpedia.com/read/Environment_Variables

Ok , makes sense, but maybe Meteor community should think about this. I see a lot of good things in Meteor, reactivity, user authentication was super easy. Even with Rails getting devise and Omnioath gems in place and generating and modifying views for them take time. Even though Meteor adds lot of magic performance seems to be better than corresponding rails app even if I don’t have any idea on how to optimise it. Just started reading bulletproof meteor around this subject.

Fullstack javascript that I am not that sure probably end up writing Coffeescript anyway and front end guy can keep his 2 screen long document ready $-sign JQuery mutants statements that are impossible to maintain nor understand… Where do people copy paste these things anyway

Mobile anyone! Rails 5 that is still in beta is the first that has websockets and API by default and and even still it you need to go and build native app to hook them into. Meteor add platform and literally only tried it few weeks back I found a really cool thing. Actually so I did blaze templates even though ppl in this forum seems to want to kill them.

How I see Meteor as one stop shop. Integrating developer workflow directly to framework is really good and functional idea. One other thing I would like to see in meteor is generators I mean having a tool within the framework to auto generate models/collections with schema validation is really good thing. That said I think that once I properly learn Meteor I can be faster on it than in Rails.

To make this framework really great steal or borrow things that work well in other frameworks.

I have never used them but there are a few generators like iron cli, meteor kithcen, mantra cli etc.

Meteor 1.3 brings in tighter integration with the javascript ecosystem and that’s also a great thing for what the future holds in all the topics you’ve referred to.

What do you exactly want borrowed from other frameworks? What do you think is missing? Becuase everything you mentioned already has a meteor/javascript counterpart.

If you are referring to environments, I’ve just told you that the way you handle it with meteor is different but it is not necessarily harder. Take a look at these approaches for example:

which hint you how flexible it is. You can do absolutely anything with these.


I have been thinking about what I am really missing and its not really the generators but the structure. I can go to any rails project and know instantly where everything is and what happens if I change it. It turn out I am not the only one. This is expecially important when working with something that you did not build from the start (most paid work…).

Josh Owens had this nice blog post around this, he also seem to have solution for it.

For something like this I want to automate my project to be build this ways is there a meteor way, or should I just use some generic generator to organise files this way?

Well, especially with 1.3 around the corner, bringing in official support for imports, this space is even more flexible now.

I’d watch out for the official meteor guide, which is to be updated very soon.