webapp

// Listen to incoming HTTP requests, can only be used on the server
WebApp.connectHandlers.use("/hello", function(req, res, next) {
  res.writeHead(200);
  res.end("Hello world from: " + Meteor.release);
});

The following are some of the more commonly used commands in the meteor 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 meteor help command.

meteor help

Get help on meteor command line usage. Running meteor help by itself will list the common meteor commands. Running meteor help command will print detailed help about the command.

meteor run

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 same as meteor run.

To pass additional options to Node.js use the NODE_OPTIONS environment variable. For example: NODE_OPTIONS='--debug' or NODE_OPTIONS='--debug-brk'

Run meteor help run to see the full list of options.

meteor debug

Run the project, but suspend the server process for debugging.

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 --debug-port <port> option to other meteor tool commands, such as meteor run and meteor test-packages.

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.

You can use the --package option, to create 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_SESSION_FILE=token.json before meteor login to generate a login session token so you don't have to share your login credentials with third-party service providers. You can revoke the token at any time from your accounts settings page.

Once you have your account you can log in and log out from the command line, and check your username with meteor whoami.

meteor deploy site

Deploy the project in your current directory to Galaxy.

You can deploy in debug mode by passing --debug. This 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 the --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 Meteor.settings.

Settings are persistent. When you redeploy your app, the old value will be preserved unless you explicitly pass new settings using the --settings option. To unset Meteor.settings, pass an empty settings file.

meteor update

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 command; 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 update --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 package@1.1.0 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 1.1.0 exactly, run 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 meteor list.

This removes the package entirely. To continue using the package, but remove its version constraint, use meteor add.

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 run meteor remove A.

meteor list

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 meteor build 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 meteor list-platforms.

meteor list-platforms

Lists all of the platforms that have been explicitly added to your project.

meteor mongo

Open a MongoDB shell on your local development database, so that you can view or manipulate it directly.

meteor reset

Reset the current project to a fresh state. Removes the local mongo database.

meteor build

Package this project up for deployment. The output is a directory with several build artifacts:

• a tarball that includes everything necessary to run the application server (see the README in the tarball for details)
• an unsigned apk bundle 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.

The unsigned 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 with the --architecture flag.

meteor lint

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.

meteor search

Searches for Meteor packages and releases, whose names contain the specified regular expression.

meteor show

Shows more information about a specific package or release: name, summary, the usernames of its maintainers, and, if specified, its homepage and git URL.

meteor publish

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: iron:router.

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 use publish-for-arch to upload a build to a different architecture from a different machine.

meteor publish-for-arch

Publishes a build of an existing package version from a different architecture.

Some packages contain code specific to an architecture. Running publish by 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.

meteor publish-release

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 it. Running 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 --create-track flag.

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.

meteor test-packages

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 --settings and --port arguments.

meteor admin

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 more information.

meteor shell

When 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 currently available, meteor shell will keep trying to connect until it succeeds.

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 Meteor, Mongo, and 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.