“meteor” vs “meteor bundle” for production

Question

For production why should I \"bundle\" the meteor application and not just copy the sources on the server use the \"meteor\" command?

Basically what is the differenc

Answer 1

When using a bundle:

1. It will not spawn meteor-mongo(Mongodb inside meteor)
2. No hot reloads
3. Meteor will not watch your files.
4. You can leave/quit the server without killing your app.
5. You can manage node processes smoothly by using pm2 or other similar npm packages.
6. You can decide where to put your mongoDB and decide what port to use.
7. You can connect to your mongodb remotely by not having to run your meteor app.

While using a copy or running meteor command in the project directory:

1. You can't leave/quit the server while keeping the project running without using any screen multiplexers (e.g. tmux)
2. You can only use meteor's assigned mongodb which is spawned in localhost:3001 -- if meteor is using port 3000.
3. You are letting meteor to watch over file changes which uses CPU.
4. When your app dies, your db dies. :)

Answer 2

This won't be an exhaustive list, but here are some things that the meteor command does:

1. creates a local database
2. watches on every dependent file in your app or in your packages
3. sends every file separately and unminified to the client (this is super inefficient unless you are developing locally)

In contrast, bundling an app:

1. does not create a local database
2. does not spend CPU watching your files for changes
3. creates two minified files (js and css) which is perfect for putting on a CDN or hosting from a reverse proxy. These are also efficient for clients to download and are highly cacheable.

In general, deploying shouldn't be a huge pain if you use a good set of scripts.