>>> (the first line of each entry is the summary for autogenerated command lists) Usage: meteor [--release ] [--help] [args] meteor help meteor [--version] [--arch] With no arguments, 'meteor' runs the project in the current directory in local development mode. You can run it from the root directory of the project or from any subdirectory. Use 'meteor create ' to create a new Meteor project. Commands: {{commands}} See 'meteor help ' for details on a command. >>> run [default] Run this project in local development mode. Usage: meteor run [platform..] [options] Searches upward from the current directory for the root directory of a Meteor project, then runs that project in local development mode. You can use the application by pointing your web browser at localhost:3000. No internet connection is required. Whenever you change any of the application's source files, the changes are automatically detected and applied to the running application. The application's database persists between runs. It's stored under the .meteor directory in the root of the project. You can specify additional platforms where the app should be run if they have been previously added with 'meteor add-platform'. By default, Meteor will run the app in an emulator. Appending "-device" to the end of a platform string (such as "android-device") will run the app on a physical device. "ios-device" will open XCode and allow you to manually run the app on a device. Options: --port, -p Port to listen on (instead of the default 3000). Also uses port N+1 and a port specified by --app-port. Specify as --port=host:port to bind to a specific interface. --debug-port Specify a port to enable server-side debugging. The server will be paused at startup, waiting for incoming connections from debugger clients on the specified port. --mobile-server Location where mobile builds connect to the Meteor server. Defaults to the host and port that the Meteor server binds to. Can include a URL scheme (for example, --mobile-server=https://example.com:443). --production Simulate production mode. Minify and bundle CSS and JS files. --raw-logs Run without parsing logs from stdout and stderr. --settings Set optional data for Meteor.settings on the server. --release Specify the release of Meteor to use. --program The program in the app to run (Advanced). --verbose Print all output from builds logs. --test [Experimental] Run Velocity tests using phantomjs and exit. >>> debug Run the project, but suspend the server process for debugging. Usage: meteor debug [--debug-port ] [run options] meteor run --debug-port [run options] 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). The easiest way to set breakpoints is to use the `debugger` keyword: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/debugger The options for 'meteor debug' are identical to those for 'meteor run', with one addition: Options: --debug-port Port on which the server process debugger should listen for incoming connections from debugging clients, such as node-inspector (default 5858). >>> create Create a new project. Usage: meteor create [--release ] meteor create [--release ] --example [] meteor create --list meteor create --package [] Make a subdirectory named and create a new Meteor app there. You can also pass an absolute or relative path. With the --package option, creates a Meteor package instead of an app. If you're in an app, the package will go in the app's top-level 'packages' directory; otherwise it will be created in the current directory. The app will use the release of Meteor specified with the --release option, or the latest available version if the option is not specified. (A package created in an app, will be created using the application's version of meteor and a package created outside a meteor app will use the latest release). You can pass --example to start off with a copy of one of the Meteor sample applications. Use --list to see the available examples. There are currently no package examples. Options: --package Create a new meteor package instead of an app. --example Example template to use. --list Show list of available examples. >>> update Upgrade this project's dependencies to their latest versions. Usage: meteor update meteor update --patch meteor update --release meteor update --packages-only meteor update [packageName packageName2 ...] Updates the meteor release, and then, if applicable, updates the packages used by the app to the latest versions that don't cause dependency conflicts with other packages in the app. Passing the --patch argument will update to the latest patch, if such exists. Patch releases contain very minor changes, usually bug fixes. Updating to the latest patch is always recommended. This will try to not update non-core packages unless strictly nessessary. Passing the --release argument will force update to a specific release of meteor. This will not update non-core packages unless strictly nessessary. It is also possible that some packages cannot be updated to be compatible with the new release. If that happens, the app will not build until dependencies on those packages are removed. Passing --packages-only will try to update non-core packages to their latest versions. It will not update the version of meteor. To update individual packages (for example: 'foo:awesome') pass in their names instead, with no options. ('meteor update foo:awesome'). Options: --packages-only Update the package versions only. Do not update the release. --patch Update the release to a patch release only. --release Update to a specific release of meteor. >>> run-upgrader Execute a specific upgrader by name. Intended for testing. Usage: meteor run-upgrader Runs a specific upgrader on the current app. This is for testing internal functionality of Meteor. >>> add Add a package to this project. Usage: meteor add [package] [package..] Adds packages to your Meteor project. You can add multiple packages with one command. To query for available packages, use the meteor search command. >>> remove Remove a package from this project. Usage: meteor remove [package] [package..] Removes a package previously added to your Meteor project. For a list of the packages that your application is currently using, see 'meteor list'. >>> list List the packages explicitly used by your project. Usage: meteor list Lists the packages that you have explicitly added to your project. This will not list transitive dependencies. >>> add-platform Add a platform to this project. Usage: meteor add-platform [platform..] Adds platforms to your Meteor project. You can add multiple platforms with one command. Available platforms: server browser android ios (on OS X only) Currently, the server and browser platforms are present in every Meteor project and cannot be removed. `meteor run` by default runs the server and browser platforms. After adding a mobile platform, you can use 'meteor run ' to run on a mobile device or emulator. 'meteor build' will always build the project for every added platform. >>> install-sdk Installs SDKs for a platform. Usage: meteor install-sdk Installs the SDK for a platform; will also verify that the platform requirements are met. Available platforms: android ios (on OS X only) >>> remove-platform Remove a platform from this project. Usage: 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'. >>> list-platforms List the platforms added to your project. Usage: meteor list-platforms Lists all of the platforms added to your project. >>> configure-android Run the Android configuration tool from Meteor's ADK environment. Usage: meteor configure-android Runs the Android configuration tool from Meteor's ADK environment. This command can be useful to configure AVDs, HAX and update the SDK. >>> bundle Deprecated command. Use 'build' instead. Deprecated command. Use 'build' instead. >>> build Outputs builds for all targeted platforms. Usage: meteor build [--debug] [--directory] [--server http://example.com:3000] 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 README in the tarball for details) - an unassigned apk bundle and a project source if Android is targeted as a mobile platform - a directory with an Xcode project source if iOS is targeted as a mobile platform Options: --debug build in debug mode (don't minify, etc) --directory output a directory (rather than a tarball) for the application server bundle. If the output location exists, it will be recursively deleted first. --server Location where mobile builds connect to the Meteor server. Defaults to localhost:3000. Can include a URL scheme (for example, --server=https://example.com:443). >>> mongo Connect to the Mongo database for the specified site. Usage: meteor mongo [--url] [site] Opens a Mongo shell to view or manipulate collections. If site is specified, this is the hosted Mongo database for the deployed Meteor site. If no site is specified, this is the current project's local development database. In this case, the current working directory must be a Meteor project directory, and the Meteor application must already be running. Instead of opening a shell, specifying --url (-U) will return a URL suitable for an external program to connect to the database. For remote databases on deployed applications, the URL is valid for one minute. Options: --url, -U return a Mongo database URL >>> reset Reset the project state. Erases the local database. Usage: meteor reset Reset the current project to a fresh state. Removes all local data. >>> deploy Deploy this project to Meteor. Usage: meteor deploy [--settings settings.json] [--debug] [--delete] Deploys the project in your current directory to Meteor's servers. You can deploy to any available name under 'meteor.com' without any additional configuration, for example, 'myapp.meteor.com'. If you deploy to a custom domain, such as 'myapp.mydomain.com', then you'll also need to configure your domain's DNS records. See the Meteor docs for details. The --settings flag can be used to pass deploy-specific information to the application. It will be available at runtime in Meteor.settings, but only on the server. If the object contains a key named 'public', then Meteor.settings.public will also be available on the client. The argument is the name of a file containing the JSON data to use. The settings will persist across deployments until you again specify a settings file. To unset Meteor.settings, pass an empty settings file. The --delete flag permanently removes a deployed application, including all of its stored data. Options: --delete, -D permanently delete this deployment --debug deploy in debug mode (don't minify, etc) --settings set optional data for Meteor.settings --star a star (tarball) to deploy instead of the current Meteor app >>> logs Show logs for specified site. Usage: meteor logs Retrieves the server logs for the requested site. >>> authorized View or change authorized users and organizations for a site. Usage: meteor authorized [--list] meteor authorized --add meteor authorized --remove Without an argument (or with --list), list the users and organizations that are administrators for a particular site that was deployed with 'meteor deploy' With --add, add an authorized user or organization to a site. Use this to give your collaborators the ability to work with your sites. With --remove, remove an authorized user or organization from a site. You cannot remove yourself. (Ask someone else who is an authorized user to do it.) You can only add or remove one authorized user at a time. Options: --add add an authorized user or organization --remove remove an authorized user or organization --list list authorized users and organizations (the default) >>> claim Claim a site deployed with an old Meteor version. Usage: meteor claim If you deployed a site with an old version of Meteor that did not have support for developer accounts, you can use this command to claim that site into your account. If you had set a password on the site you will be prompted for it one last time. >>> login Log in to your Meteor developer account. Usage: meteor login [--email] Prompts for your username and password and logs you in to your Meteor developer account. Pass --email to log in by email address rather than by username. >>> logout Log out of your Meteor developer account. Usage: meteor logout Log out of your Meteor developer account. >>> whoami Prints the username of your Meteor developer account. Usage: meteor whoami Prints the username of the currently logged-in Meteor developer. See 'meteor login' to log into or 'meteor logout' to log out of your Meteor developer account. >>> test-packages Test one or more packages. Usage: meteor test-packages [--release ] [options] [package...] Runs unit tests for one or more packages. The results are shown in a browser dashboard that updates whenever a relevant source file is modified. Packages may be specified by name or by path. If a package argument contains a '/', it is loaded from a directory of that name; otherwise, the package name is resolved according to the usual package search algorithm ('packages' subdirectory of the current app, $PACKAGE_DIRS directories, and core packages in that order). You can test any number of packages simultaneously. If you don't specify any package names then all available packages will be tested. Open the test dashboard in your browser to run the tests and see the results. By default the URL is localhost:3000 but that can be changed with --port. Alternatively, you can deploy the tests onto the 'meteor deploy' server by using --deploy. This gives you a public URL that you can use in conjunction with a service like Browserling or BrowserStack to try the tests against many different browser versions. Options: --port, -p Port to listen on (instead of the default 3000). Also uses port N+1 and N+2. --debug-port Specify a port to enable server-side debugging. The server will be paused before any tests run, waiting for incoming connections from debugger clients. --mobile-server If running tests in an emulator or on a mobile device, the location where mobile builds connect to the Meteor server. Defaults to the host and port that the Meteor server binds to. Can include a URL scheme (for example, --mobile-server=https://example.com:443). --deploy Optionally, specify a domain to deploy to, rather than running locally. --production Simulate production mode. Minify and bundle CSS and JS files. --settings Set optional data for Meteor.settings on the server --ios, Run tests in an emulator or on a mobile device. All of --android, the tests for client and server will run in addition to --ios-device, mobile-specific tests. --android-device --test-app-path Set the location where to create and run a temporary app used for tests. Defaults to systems temporary directory /tmp. --verbose Print all output from builds logs. >>> self-test Run tests of the 'meteor' tool. Usage: meteor self-test [pattern] [--list] [--file pattern] [--changed] [--slow] [--force-online] [--history n] [--browserstack] Runs internal tests. Exits with status 0 on success. If 'pattern' is provided, it should be a regular expression. Only tests that match the regular expression will be run. Use --list to list the tests that would be run according to the other options, without running them. Pass --file to run only tests in files that match the regular expression. Pass --changed to run only tests that have changed since they last passed. This uses a really rough heuristic: A test has changed iff there has been any change to the file in the 'selftests' subdirectory that defines it. State for this is tracked in ~/.meteortest. Some tests are really slow. Test flagged as slow won't be run unless you pass --slow. Remember to do this from time to time! Normally, this command detects whether you are offline and skips tests that require network access automatically. If you want to try to run them anyway, pass --force-online. Use --history to change the number of lines of program output that are shown on test failure. The default is 10. Pass --browserstack to enable client side tests using BrowserStack. --browserstack requires s3cmd credentials. >>> open-ide Open mobile build project in associated IDE. Usage: meteor open-ide [ios] Open mobile build project in associated IDE. >>> admin Administrative commands. Usage: meteor admin [args] meteor help admin Rarely used commands for administering official Meteor services. Commands: {{commands}} See 'meteor help admin ' for details on an admin command. >>> admin make-bootstrap-tarballs Makes bootstrap tarballs. Usage: meteor admin make-bootstrap-tarballs release@version /tmp/tarballdir For internal use only. >>> dummy Dummy command used for automated testing. Usage: meteor dummy [options] Dummy command used for automated testing. Options: --email, -e A required string option. --port, -p A numeric option with a short alias. --changed A boolean option. >>> cordova Run cordova commands. Usage: meteor cordova >>> list-sites List sites for which you are authorized. Usage: meteor list-sites List the sites that you have deployed with 'meteor deploy', and sites for which other users have authorized you with the 'meteor authorized' command. >>> publish-release Publish a new meteor release to the package server. Usage: meteor publish-release [--create-track] Publishes a new release to the package server, as determined by the json configuration file, which must have the following keys: track: the release track to which you are publishing (ex: METEOR) version: the version of this release recommended: is this a recommended release? (see below) description: a brief description of the release patchFrom: (Optional) an array of strings specifying releases from which this is a patch tool: @ of the meteor tool that this release specifies packages: object of to for specified package versions Set the recommended flag to true for recommended releases (ex: METEOR@0.90) and false for release candidates, experimental releases, etc. You must publish all package versions to the package server before you can specify them in a release. Use the patchFrom flag to submit a patch release. This will automatically unrecommend the releases specified by the patchFrom flag. Use the --create-track to publish a new release track. Options: --create-track publish a new release track. >>> publish Publish a new version of a package to the package server. Usage: meteor publish [--create] Publishes a new version of a local package to the package server. Must be run from the directory containing the package. Reads the package.js file for version information, builds the package and sends both the package source and the built version of the package to the package server. This will only create one build of the package. If your package has multiple builds for different OS architectures, it will create a build for this machine's architecture. To publish a different build for the same version, run publish-for-arch. This will mark you as the only maintainer of the package. If you need to change maintainers and other metadata about this package & package version, take a look at the admin commands. Pass --create to create a new package. Options: --create publish a new package >>> publish-for-arch Builds an already-published package for a new platform. Usage: meteor publish-for-arch packageName@version When you publish a package with 'meteor publish' for a package which has platform-specific components (eg, npm modules with native code), the package will only be usable on machines of the same architecture that you are currently on. To make your package's version usable on other architectures, you can use the publish-for-arch command. (The architectures currently supported by Meteor are 32-bit Linux, 64-bit Linux, and 64-bit OS X; the 'meteor deploy' servers use 64-bit Linux.) On a machine of the appropriate architecture, install Meteor and run $ meteor publish-for-arch packageName@version You don't need to have a copy of your package's source to do this: Meteor will automatically download your package's source and dependencies from the package server. >>> rebuild Rebuild local packages. Usage: meteor rebuild [] Rebuild a specified local packages. Deletes the package's build directory and rebuilds the package from scratch. Please specify the package by name. If you pass no arguments, this will rebuild all local packages. That includes packages found through the PACKAGE_DIRS environment variable, local packages in the current application, and, if running Meteor from a checkout, the packages in the checkout. It doesn't include any packages for which we don't have the source. You should never need to use this command. It is intended for use while debugging the Meteor packaging tools themselves. >>> search Search through the package server database. Usage: meteor search [--maintainer ] [--show-old] Search through the meteor package&release database for names containing the specified substring. Use --maintainer to filter by authorized maintainers. By default, meteor search will not show packages that, due to migration issues, are known to not be compatible with Meteor 0.9.0 and later. If you want to see those packages anyway, use the --show-old option. By default, meteor search will not show packages that have no official versions (ie: non-pre-release versions) If you want to see those packages anyway, use the --show-rcs option. Options: --maintainer filter by authorized maintainer --show-old show packages incompatible with Meteor 0.9.0 and later. --show-rcs show packages with no non-prerelease versions >>> show Show detailed information about a release or package. Usage: meteor show meteor show Show detailed information on a specific package or release, including available versions. Use @ to get more information about a specific version of a package or release. By default, meteor show will not show versions that, due to migration issues, are known to not be compatible with Meteor 0.9.0 and later. If you want to see those versions anyway, use the --show-old option. Options: --maintainer filter by authorized maintainer --show-old show versions incompatible with Meteor 0.9.0 and later. >>> admin maintainers View or change package maintainers. Usage: meteor admin maintainers [--list] meteor admin maintainers --add meteor admin maintainers --remove Without options (or with --list), list the users and organizations that are maintainers for a particular package. With --add, add an authorized maintainer to a package. Use this to give your collaborators the ability to work with your packages. With --remove, remove an authorized maintainer from a package. You cannot remove yourself if you are the last maintainer on a package. You can only add or remove one maintainer at a time. Options: --add add an authorized maintainer --remove remove an authorized maintainer --list list authorized maintainers (the default) >>> admin recommend-release Recommend a previously published release. Usage: meteor admin recommend-release @ [--unrecomend] Recommend a version of a meteor release. Users can be upgraded to recommended releases automatically when they run meteor update. Users will never be updated to unrecommended releases unless they explicitly specify that release with a --release argument. Use unrecommended releases for release candidates, one-of experiments, etc. Use recommended releases for official supported releases. Options: --unrecommend unrecommend a previously recommended release >>> admin change-homepage Change the homepage url of a package. Usage: meteor admin change-homepage Change the homepage containing package information. >>> admin set-unmigrated Set the package as unmigrated. Usage: meteor admin set-unmigrated [--success] meteor admin set-unmigrated @ [--success] Set a version of a package, as unmigrated: make it invisible in search and show, without a special option. (You should use this to hide packages that have been renamed in the aftermath of the 0.9.0 migration.) This will not stop the users from adding the package to their app. If no version is passed in, all versions will be set. Use the --success option to mark the package version as successfully migrated, making it show up again. Options: --success mark the package as successfully migrated. >>> admin set-banners Set banners on published releases. Usage: meteor admin set-banners Set the banners on previously published releases. Banners notify the user when there is a new release available or a patch release has been published. >>> admin list-organizations List the organizations of which you are a member. Usage: meteor list-organizations List the organizations of which you are a member. >>> admin members View or change the members of an organization. Usage: meteor admin members [--list] meteor admin members --add meteor admin members --remove Without options, list the members of an organization. With --add or --remove, add or remove a member of an organization. Options: --add add a member to the organization --remove remove a member from the organization --list list members of the organization (the default) >>> admin set-latest-readme Set the readme on the latest version of a core meteor package. Usage: meteor admin set-latest-core-readme name --commit commit meteor admin set-latest-core-readme name --tag tag Set the readme field on the latest published version of a core package to the readme at a given git commit, or the readme at a given git tag. >>> admin get-machine Open an ssh shell to a machine in the meteor build farm. Usage: meteor admin get-machine [--json] [--verbose] [--length min] Asks the meteor build farm for a build server and opens a secure shell to it. Reservations are capped at 15 minutes at a time, and 60 minutes per week. Default reservation length is 5 minutes. Pass in the --json option to get a json of authentication information and open the shell manually. Options: --json return information as json instead of opening a shell --length specify the length of the reservation --verbose print all output from commands