The following are some of the more commonly used commands in the
command-line tool. This is just an overview and does not mention every command
or every option to every command; for more details, use the
Get help on meteor command line usage. Running
meteor help by
itself will list the common meteor
meteor help command will print
detailed help about the command.
Run a meteor development server in the current project. Searches upward from the current directory for the root directory of a Meteor project. Whenever you change any of the application’s source files, the changes are automatically detected and applied to the running application.
You can use the application by pointing your web browser at localhost:3000. No Internet connection is required.
This is the default command. Simply running
meteor is the
To pass additional options to Node.js use the
NODE_OPTIONS environment variable.
To specify a port to listen on (instead of the default 3000), use
(The development server also uses port
N+1 for the default MongoDB instance)
meteor run --port 4000
will run the development server on
and the development MongoDB instance on
meteor help run to see the full list of options.
Run the project, but suspend the server process for debugging.
meteor debugcommand has been superseded by the more flexible
--inspect-brkcommand-line flags, which work for any
The syntax of these flags is the same as the equivalent Node.js flags, with two notable differences:
The flags affect the server process spawned by the build process, rather than affecting the build process itself.
--inspect-brkflag causes the server process to pause just after server code has loaded but before it begins to execute, giving the developer a chance to set breakpoints in server code.
The server process will be suspended just before the first statement of server code that would normally execute. In order to continue execution of server code, use either the web-based Node Inspector or the command-line debugger (further instructions will be printed in the console).
Breakpoints can be set using the
debugger keyword, or through the web UI of Node Inspector (“Sources” tab).
The server process debugger will listen for incoming connections from
debugging clients, such as node-inspector, on port 5858 by default. To
specify a different port use the
--debug-port <port> option.
The same debugging functionality can be achieved by adding the
option to other
meteor tool commands, such as
meteor run and
Note: Due to a bug in
node-inspector, pushing “Enter” after a command on the Node Inspector Console will not successfully send the command to the server. If you require this functionality, please consider using Safari or
meteor shellin order to interact with the server console until the
node-inspectorproject fixes the bug. Alternatively, there is a hot-patch available in this comment on #7991.
meteor create name
Create a new Meteor project. By default, makes a subdirectory named name and copies in the template app. You can pass an absolute or relative path.
Creates a basic, empty project.
Creates a project with as few Meteor Packages as possible.
Creates a new package. If used in an existing app, this command will create a package in the packages directory.
meteor login / logout
Log in and out of your account using Meteor’s authentication system.
You can pass
meteor login to generate
a login session token so you don’t have to share your login credentials with
third-party service providers.
Once you have your account you can log in and log out from the command line, and
check your username with
meteor deploy site
Deploy the project in your current directory to Galaxy.
--owner to decide which organization or user account you’d like to deploy
a new app to if you are a member of more than one Galaxy-enabled account.
You can deploy in debug mode by passing
will leave your source code readable by your favorite in-browser
debugger, just like it is in local development mode.
To delete an application you’ve deployed, specify
--delete option along with the site.
You can add information specific to a particular deployment of your application
by using the
--settings option. The argument to
--settings is a file
containing any JSON string. The object in your settings file will appear on the
server side of your application in
Settings are persistent. When you redeploy your app, the old value will be
preserved unless you explicitly pass new settings using the
Meteor.settings, pass an empty settings file.
Attempts to bring you to the latest version of Meteor, and then to upgrade your packages to their latest versions. By default, update will not break compatibility.
For example, let’s say packages A and B both depend on version 1.1.0 of package
X. If a new version of A depends on X@2.0.0, but there is no new version of
package B, running
meteor update will not update A, because doing so will
break package B.
You can pass in the flag
--packages-only to update only the packages, and not
the release itself. Similarly, you can pass in names of packages
meteor update foo:kittens baz:cats) to only update specific packages.
Every project is pinned to a specific release of Meteor. You can temporarily try
using your package with another release by passing the
--release option to any
meteor update changes the pinned release.
Sometimes, Meteor will ask you to run
meteor update --patch. Patch releases
are special releases that contain only very minor changes (usually crucial bug
fixes) from previous releases. We highly recommend that you always run
--patch when prompted.
You may also pass the
--release flag to act as an override to update to a
specific release. This is an override: if it cannot find compatible versions of
packages, it will log a warning, but perform the update anyway. This will only
change your package versions if necessary.
meteor add package
Add packages to your Meteor project. By convention, names of community packages
include the name of the maintainer. For example:
meteor add iron:router. You
can add multiple packages with one command.
Optionally, adds version constraints. Running
meteor add firstname.lastname@example.org will
add the package at version
1.1.0 or higher (but not
2.0.0 or higher). If you
want to use version
1.1.0 exactly, use
meteor add package@=1.1.0. You can also
‘or’ constraints together: for example,
meteor add 'package@=1.0.0 || =2.0.1'
means either 1.0.0 (exactly) or 2.0.1 (exactly).
To remove a version constraint for a specific package, run
meteor add again
without specifying a version. For example above, to stop using version
meteor add package.
meteor remove package
Removes a package previously added to your Meteor project. For a
list of the packages that your application is currently using, run
This removes the package entirely. To continue using the package,
but remove its version constraint, use
Meteor does not downgrade transitive dependencies unless it’s necessary. This
means that if running
meteor add A upgrades A’s parent package X to a new
version, your project will continue to use X at the new version even after you
meteor remove A.
Lists all the packages that you have added to your project. For each package, lists the version that you are using. Lets you know if a newer version of that package is available.
meteor add-platform platform
Adds platforms to your Meteor project. You can add multiple
platforms with one command. Once a platform has been added, you
can use ‘meteor run platform‘ to run on the platform, and
to build the Meteor project for every added platform.
meteor remove-platform platform
Removes a platform previously added to your Meteor project. For a
list of the platforms that your application is currently using, see
Lists all of the platforms that have been explicitly added to your project.
Open a MongoDB shell on your local development database, so that you can view or manipulate it directly.
For now, you must already have your application running locally with
meteor run. This will be easier in the future.
Reset the current project to a fresh state. Removes the local mongo database.
This deletes your data! Make sure you do not have any information you care about in your local mongo database by running
meteor mongo. From the mongo shell, use
db.collection.find()to inspect your data.
For now, you can not run this while a development server is running. Quit all running meteor applications before running this.
Package this project up for deployment. The output is a directory with several build artifacts:
- a tarball (.tar.gz) that includes everything necessary to run the application
server (see the
READMEin the tarball for details). Using the
--directoryoption will produce a
bundledirectory instead of the tarball.
- an unsigned
apkbundle and a project source if Android is targetted as a mobile platform
- a directory with an Xcode project source if iOS is targetted as a mobile platform
You can use the application server bundle to host a Meteor application on your own server, instead of deploying to Galaxy. You will have to deal with logging, monitoring, backups, load-balancing, etc, all of which we handle for you if you use Galaxy.
apk bundle and the outputted Xcode project can be used to deploy
your mobile apps to Android Play Store and Apple App Store.
By default, your application is bundled for your current architecture.
This may cause difficulties if your app contains binary code due to,
for example, npm packages. You can try to override that behavior
Run through the whole build process for the app and run all linters the app uses. Outputs all build errors or linting warnings to the standard output.
Searches for Meteor packages and releases, whose names contain the specified regular expression.
Shows more information about a specific package or release: name, summary, the usernames of its maintainers, and, if specified, its homepage and git URL.
Publishes your package. To publish, you must
cd into the package directory, log
in with your Meteor Developer Account and run
meteor publish. By convention,
published package names must begin with the maintainer’s Meteor Developer
Account username and a colon, like so:
To publish a package for the first time, use
meteor publish --create.
Sometimes packages may contain binary code specific to an architecture (for
example, they may use an npm package). In that case, running publish will only
upload the build to the architecture that you were using to publish it. You can
publish-for-arch to upload a build to a different architecture from a
Publishes a build of an existing package version from a different architecture.
Some packages contain code specific to an architecture. Running
itself, will upload the build to the architecture that you were using to
publish. You need to run
publish-for-arch from a different architecture to
upload a different build.
For example, let’s say you published name:cool-binary-blob from a Mac. If you
want people to be able to use cool-binary-blob from Linux, you should log into a
Linux machine and then run
meteor publish-for-arch name:cool-binary-blob@version. It will notice that you
are on a linux machine, and that there is no Linux-compatible build for your package
and publish one.
Currently, the supported architectures for Meteor are 32-bit Linux, 64-bit Linux and Mac OS. Galaxy’s servers run 64-bit Linux.
Publishes a release of Meteor. Takes in a JSON configuration file.
Meteor releases are divided into tracks. While only MDG members can publish to
the default Meteor track, anyone can create a track of their own and publish to
meteor update without specifying the
--release option will not
cause the user to switch tracks.
To publish to a release track for the first time, use the
The JSON configuration file must contain the name of the release track
track), the release version (
version), various metadata, the packages
specified by the release as mapped to versions (
packages), and the package &
version of the Meteor command-line tool (
tool). Note that this means that
forks of the meteor tool can be published as packages and people can use them by
switching to a corresponding release. For more information, run
meteor help publish-release.
Test Meteor packages, either by name, or by directory. Not specifying an
argument will run tests for all local packages. The results are displayed in an
app that runs at
localhost:3000 by default. If you need to, you can pass the
Catch-all for miscellaneous commands that require authorization to use.
Some example uses of
meteor admin include adding and removing package
maintainers and setting a homepage for a package. It also includes various
helpful functions for managing a Meteor release. Run
meteor help admin for
meteor shell is executed in an application directory where a server
is already running, it connects to the server and starts an interactive
shell for evaluating server-side code.
Multiple shells can be attached to the same server. If no server is
meteor shell will keep trying to connect until it
Exiting the shell does not terminate the server. If the server restarts
because a change was made in server code, or a fatal exception was
encountered, the shell will restart along with the server. This behavior
can be simulated by typing
.reload in the shell.
The shell supports tab completion for global variables like
Package. Try typing
Meteor.is and then pressing tab.
The shell maintains a persistent history across sessions. Previously-run commands can be accessed by pressing the up arrow.
meteor npm command calls the
npm version bundled
with Meteor itself.
Additional parameters can be passed in the same way as the
meteor npm rebuild,
meteor npm ls, etc.) and the
npm documentation should be consulted for the
full list of commands and for a better understanding of their usage.
For example, executing
meteor npm install lodash --save would install
from npm to your
node_modules directory and save its usage in your
meteor npm ... commands in place of traditional
npm ... commands
is particularly important when using Node.js modules that have binary
dependencies that make native C calls (like
because doing so ensures that they are built using the same libaries.
Additionally, this access to the npm that comes with Meteor avoids the need to download and install npm separately.
meteor node command calls the
node version bundled with Meteor itself.
This is not to be confused with
meteor shell, which provides an almost identical experience but also gives you access to the “server” context of a Meteor application. Typically,
meteor shellwill be preferred.
Additional parameters can be passed in the same way as the
node command, and
the Node.js documentation
should be consulted for the full list of commands and for a better understanding
of their usage.
For example, executing
meteor node will enter the Node.js
meteor node -e "console.log(process.versions)" would
console.log(process.versions) in the version of
node bundled with Meteor.