Skip to content

Command Line

Documentation of the various command line options of the Meteor tool.


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.

bash
meteor help

Lists the common meteor commands.

bash
meteor help <command>

Prints detailed help about the specific command.

meteor run

Run a meteor development server in the current project.

bash
meteor run

TIP

This is the default command. Simply running meteor is the same as meteor run.

Features

  • Automatically detects and applies changes to your application's source files
  • No Internet connection required
  • Accesses the application at localhost:3000 by default
  • Searches upward from the current directory for the root directory of a Meteor project

Options

OptionDescription
--port, -p <port>Port to listen on (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
--open, -oOpens a browser window when the app starts
--inspect[-brk][=<port>]Enable server-side debugging via debugging clients. With --inspect-brk, pauses at startup (default port: 9229)
--mobile-server <url>Location where mobile builds connect (defaults to local IP and port). Can include URL scheme (e.g., https://example.com:443)
--cordova-server-port <port>Local port where Cordova will serve content
--productionSimulate production mode. Minify and bundle CSS and JS files
--raw-logsRun without parsing logs from stdout and stderr
--settings, -s <file>Set optional data for Meteor.settings on the server
--release <version>Specify the release of Meteor to use
--verbosePrint all output from builds logs
--no-lintDon't run linters used by the app on every rebuild
--no-release-checkDon't run the release updater to check for new releases
--allow-incompatible-updateAllow packages to be upgraded or downgraded to potentially incompatible versions
--extra-packages <packages>Run with additional packages (comma separated, e.g., "package-name1, package-name2@1.2.3")
--exclude-archs <archs>Don't create bundles for certain web architectures (comma separated, e.g., "web.browser.legacy, web.cordova")

Node.js Options

To pass additional options to Node.js, use the SERVER_NODE_OPTIONS environment variable:

Windows PowerShell:

powershell
$env:SERVER_NODE_OPTIONS = '--inspect' | meteor run

Linux/macOS:

bash
SERVER_NODE_OPTIONS=--inspect-brk meteor run

Port Configuration Example

bash
meteor run --port 4000

This command:

  • Runs the development server on http://localhost:4000
  • Runs the development MongoDB instance on mongodb://localhost:4001

INFO

The development server always uses port N+1 for the default MongoDB instance, where N is the application port.

meteor debug

Run the project with the server process suspended for debugging.

Deprecation Notice

The meteor debug command has been superseded by the more flexible --inspect and --inspect-brk command-line flags, which work with run, test, and test-packages commands.

Modern Debugging Approach

bash
# Debug server with auto-attachment
meteor run --inspect

# Debug server and pause at start
meteor run --inspect-brk

Command Usage

bash
meteor debug [--debug-port <port>]

How It Works

  • Server process suspends just before the first statement of server code execution
  • Debugger listens for incoming connections on port 5858 by default
  • Use --debug-port <port> to specify a different port

Setting Breakpoints

  • Use the debugger keyword in your code
  • Set breakpoints through the debugging client's UI (e.g., in the "Sources" tab)

Debugging Clients

You can use either:

  • Web-based Node Inspector
  • Command-line debugger
Node Inspector Console Bug

Due to a bug in node-inspector, pressing "Enter" after a command in the Node Inspector Console may not successfully send the command to the server.

Workarounds:

  • Use Safari browser
  • Use meteor shell to interact with the server console
  • Apply the hot-patch available in this comment

Differences from Node.js Flags

The Meteor --inspect and --inspect-brk flags work similarly to Node.js flags with two key differences:

  1. They affect the server process spawned by the build process, not the build process itself
  2. The --inspect-brk flag pauses execution after server code has loaded but before it begins to execute

Alternative Approach

The same debugging functionality can be achieved by adding the --debug-port <port> option to other Meteor commands:

bash
meteor run --debug-port 5858
meteor test-packages --debug-port 5858

meteor profile

Run a performance profile for your Meteor application to analyze build and bundling performance.

bash
meteor profile [<meteor-run-options>...]

Availability

This command is available from Meteor 3.2 and newer.

Usage

This command monitors the bundler process and tracks key performance metrics to help analyze build and bundling performance.

Options

OptionDescription
--sizeMonitor both bundle runtime and size
--size-onlyMonitor only the bundle size

INFO

All other options from meteor run are also supported (e.g., --settings, --exclude-archs).

Environment Variables

VariableDescriptionDefault
METEOR_IDLE_TIMEOUT=<seconds>Set a timeout for profiling90 seconds
METEOR_CLIENT_ENTRYPOINT=<path>Set a custom client entrypointFrom package.json
METEOR_SERVER_ENTRYPOINT=<path>Set a custom server entrypointFrom package.json
METEOR_LOG_DIR=<path>Set a custom log directoryDefault log directory

TIP

The default timeout (90s) is usually enough for each build step to complete. If you encounter errors due to early exits, increase the METEOR_IDLE_TIMEOUT value.

Example Usage

bash
# Basic profile
meteor profile

# Monitor bundle size only
meteor profile --size-only

# Profile with custom settings and timeout
METEOR_IDLE_TIMEOUT=120 meteor profile --settings settings.json

# Profile with custom entrypoints
METEOR_CLIENT_ENTRYPOINT=client/main.js METEOR_SERVER_ENTRYPOINT=server/main.js meteor profile
Customizing the Profiling Process

You can pass any option that works with meteor run to customize the profiling process. This allows you to profile your application under specific conditions that match your deployment environment.

meteor create app-name

Create a new Meteor project in a directory called app-name.

bash
meteor create [options] app-name

Default Behavior

Without any flags, meteor create app-name generates a React project.

Interactive Wizard

If you run meteor create without arguments, Meteor will launch an interactive wizard that guides you through selecting your project name and application type:

bash
  ~ What is the name/path of your app?
  ~ Which skeleton do you want to use?
  Blaze     # To create an app using Blaze
  Full      # To create a more complete scaffolded app
  Minimal   # To create an app with as few Meteor packages as possible
  React     # To create a basic React-based app
  Typescript # To create an app using TypeScript and React
  Vue       # To create a basic Vue3-based app
  Svelte    # To create a basic Svelte app
  Tailwind # To create an app using React and Tailwind 
  Chakra-ui # To create an app Chakra UI and React 
  Solid # To create a basic Solid app 
  Apollo # To create a basic Apollo + React app 
  Bare # To create an empty app

Basic Options

OptionDescription
--from <url>Clone a Meteor project from a URL
--example <name>Use a specific example template
--listShow list of available examples
--release <version>Specify Meteor version (e.g., --release 2.8)
--prototypeInclude autopublish and insecure packages for rapid prototyping (not for production)

Application Types

OptionDescriptionTutorial / Example
--reactCreate a React app (default)Meteor 3 with React, Meteor 2 with React
--vueVue 3 + Tailwind CSS + ViteMeteor 3 with Vue, Meteor 2 with Vue
--svelteSvelteMeteor 2 with Svelte
--blazeBasic Blaze appMeteor 2 with Blaze
--solidSolid + ViteMeteor 2 with Solid Example
--apolloReact + Apollo (GraphQL)Meteor 2 with GraphQL
--typescriptReact + TypeScriptTypeScript Guide
--tailwindReact + Tailwind CSS-
--chakra-uiReact + Chakra UISimple Tasks Example

Project Structure Options

OptionDescription
--minimalCreate with minimal Meteor packages
--bareCreate an empty app (Blaze + MongoDB)
--fullCreate a fully scaffolded app with imports-based structure (Blaze + MongoDB)
--packageCreate a new package instead of an application

Prototype Mode

The --prototype option adds packages that make development faster but shouldn't be used in production. See the security checklist.

Included Packages

React App (--react or default)

NPM packages:

  • @babel/runtime, meteor-node-stubs, react, react-dom

Meteor packages:

  • meteor-base, mobile-experience, mongo, reactive-var, standard-minifier-css, standard-minifier-js, es5-shim, ecmascript, typescript, shell-server, hot-module-replacement, static-html, react-meteor-data
Apollo (GraphQL) App (--apollo)

NPM packages:

  • @apollo/client, @apollo/server, @babel/runtime, graphql meteor-node-stubs, react, react-dom

Meteor packages:

  • meteor-base, mobile-experience, mongo, reactive-var, standard-minifier-css, standard-minifier-js, es5-shim, ecmascript, typescript, shell-server, hot-module-replacement, static-html, apollo, compat:graphql
Blaze App (--blaze)

NPM packages:

  • @babel/runtime, meteor-node-stubs, jquery

Meteor packages:

  • meteor-base, mobile-experience, mongo, blaze-html-templates, jquery, reactive-var, tracker, standard-minifier-css, standard-minifier-js, es5-shim, ecmascript, typescript, shell-server, hot-module-replacement, blaze-hot
Vue App (--vue)

NPM packages:

  • @babel/runtime, meteor-node-stubs, vue, vue-meteor-tracker, vue-router, @types/meteor, @vitejs/plugin-vue, autoprefixer, meteor-vite, postcss, tailwindcss, vite

Meteor packages:

  • meteor-base, mobile-experience, mongo, reactive-var, standard-minifier-css, standard-minifier-js, es5-shim, ecmascript, typescript, shell-server, hot-module-replacement, static-html, jorgenvatle:vite
Minimal App (--minimal)

NPM packages:

  • @babel/runtime, meteor-node-stubs

Meteor packages:

  • meteor, standard-minifier-css, standard-minifier-js, es5-shim, ecmascript, typescript, shell-server, static-html, webapp, ddp, server-render, hot-module-replacement

File Structure

To learn more about the recommended file structure for Meteor apps, check the Meteor Guide.

meteor generate

meteor generate is a command to generate boilerplate for your current project. meteor generate receives a name as a parameter, and generates files containing code to create a Collection with that name, Methods to perform basic CRUD operations on that Collection, and a Subscription to read its data with reactivity from the client.

If you run meteor generate without arguments, it will ask you for a name, and name the auto-generated Collection accordingly. It will also ask if you do want Methods for your API and Publications to be generated as well.

Important to note: By default, the generator will generate JavaScript code. If you have a tsconfig.json file in your project, it will generate TypeScript code instead.

Example:

bash
meteor generate customer

Running the command above will generate the following code in /imports/api:

Screenshot 2022-11-09 at 11 28 29

That will have the following code:

collection.js

js
import { Mongo } from 'meteor/mongo';

export const CustomerCollection = new Mongo.Collection('customer');

methods.js

js
import { Meteor } from 'meteor/meteor';
import { check } from 'meteor/check';
import { CustomerCollection } from './collection';

export async function create(data) {
  return CustomerCollection.insertAsync({ ...data });
}

export async function update(_id, data) {
  check(_id, String);
  return CustomerCollection.updateAsync(_id, { ...data });
}

export async function remove(_id) {
  check(_id, String);
  return CustomerCollection.removeAsync(_id);
}

export async function findById(_id) {
  check(_id, String);
  return CustomerCollection.findOneAsync(_id);
}

Meteor.methods({
  'Customer.create': create,
  'Customer.update': update,
  'Customer.remove': remove,
  'Customer.find': findById
});

publication.js

js
import { Meteor } from 'meteor/meteor';
import { CustomerCollection } from './collection';

Meteor.publish('allCustomers', function publishCustomers() {
  return CustomerCollection.find({});
});

index.js

js
export * from './collection';
export * from './methods';
export * from './publications';

path option

If you want the generated files to be placed in a specific directory, you can use the --path option to tell meteor generate where to place the new files. In the example below, meteor generate will create a collection called another-customer and place the collection.ts, methods.ts, publications.ts and index.ts files inside the server/admin directory. In this example, we will assume the user has a tsconfig.json file in their project folder, and generate TypeScript instead.

bash

meteor generate another-customer --path=server/admin

It will generate our files in the server/admin folder:

Screenshot 2022-11-09 at 11 32 39

collection.ts

typescript
import { Mongo } from 'meteor/mongo';

export type AnotherCustomer = {
  _id?: string;
  name: string;
  createdAt: Date;
}

export const AnotherCustomerCollection = new Mongo.Collection<AnotherCustomer>('another-customer');

methods.ts

typescript
import { Meteor } from 'meteor/meteor';
import { Mongo } from 'meteor/mongo';
import { check } from 'meteor/check';
import { AnotherCustomer, AnotherCustomerCollection } from './collection';

export async function create(data: AnotherCustomer) {
  return AnotherCustomerCollection.insertAsync({ ...data });
}

export async function update(_id: string, data: Mongo.Modifier<AnotherCustomer>) {
  check(_id, String);
  return AnotherCustomerCollection.updateAsync(_id, { ...data });
}

export async function remove(_id: string) {
  check(_id, String);
  return AnotherCustomerCollection.removeAsync(_id);
}

export async function findById(_id: string) {
  check(_id, String);
  return AnotherCustomerCollection.findOneAsync(_id);
}

Meteor.methods({
  'AnotherCustomer.create': create,
  'AnotherCustomer.update': update,
  'AnotherCustomer.remove': remove,
  'AnotherCustomer.find': findById
});

publications.ts

typescript
import { Meteor } from 'meteor/meteor';
import { AnotherCustomerCollection } from './collection';

Meteor.publish('allAnotherCustomers', function publishAnotherCustomers() {
  return AnotherCustomerCollection.find({});
});

index.ts

typescript
export * from './collection';
export * from './methods';
export * from './publications';

Using the Wizard

Running meteor-generate without arguments will start a little wizard in your terminal, which will ask you the name of your Collection, and whether you want Methods and Publications to be generated as well.

bash
meteor generate

Screenshot 2022-11-09 at 11 38 29


Using your own template

You may customize the output of meteor generate by providing a directory with a "template". A template directory is just a folder provide by you with .js/.ts files, which are copied over.

To use an user-provided template, you should pass in a template directory URL so that it can copy it with its changes.

--templatePath

bash
meteor generate feed --templatePath=/scaffolds-ts

Screenshot 2022-11-09 at 11 42 47

Note that this is not a full-blown CLI framework inside Meteor. meteor generate is just a command for generating code that is common in Meteor projects. Check out Yargs, Inquirer or Commander for more information about CLI frameworks.

How to rename things?

In addition to your own template folder, you can pass a JavaScript file to meteor-generate to perform certain transformations in your template files. That file is just a normal .js file that should export two functions: transformName and transformContents, which are used to modify the file names and contents, respectively.

If you don't want to write such a file yourself, a few functions are provided out of the box to replace strings like $$name$$, $$PascalName$$ and $$camelName$$ in your template files. The internal Meteor template files (which is used when you don't pass a template folder through the --templatePath option) are implemented this way - they include those special strings which get replaced to generate your files.

These replacements come from this function from Meteor's CLI:

scaffoldName is a string with the name that you have passed as argument.

js
const transformName = (name) => {
    return name.replace(/\$\$name\$\$|\$\$PascalName\$\$|\$\$camelName\$\$/g, function (substring, args) {
      if (substring === '$$name$$') return scaffoldName;
      if (substring === '$$PascalName$$') return toPascalCase(scaffoldName);
      if (substring === '$$camelName$$') return toCamelCase(scaffoldName);
    })
  }

How to replace things in your own templates?

--replaceFn

If you do want to customize how your templates are generated, you can pass a .js file with the --replaceFn option, as described above. When you pass in given a .js file with an implementation for those two functions, Meteor will use your functions instead of the default ones.

example of a replacer file

js
export function transformFilename(scaffoldName, filename) {
  console.log(scaffoldName, filename);
  return filename;
}

export function transformContents(scaffoldName, fileContents, filename) {
  console.log(filename, fileContents);
  return contents;
}

If you run your command like this:

bash
 meteor generate feed --replaceFn=/fn/replace.js

It will generate files full of $$PascalCase$$ strings using the Meteor provided templates, ignoring the name provided by the user (feed). Since we aren't replacing them with anything in the example above, the Meteor template files are copied as they are.

A more real-world usage of this feature could be done with the following .js file:

js
const toPascalCase = (str) => {
  if(!str.includes('-')) return str.charAt(0).toUpperCase() + str.slice(1);
  else return str.split('-').map(toPascalCase).join('');
}
const toCamelCase = (str) => {
  if(!str.includes('-')) return str.charAt(0).toLowerCase() + str.slice(1);
  else return str.split('-').map(toPascalCase).join('');
}

const transformName = (scaffoldName, str) => {
    return str.replace(/\$\$name\$\$|\$\$PascalName\$\$|\$\$camelName\$\$/g, function (substring, args) {
      if (substring === '$$name$$') return scaffoldName;
      if (substring === '$$PascalName$$') return toPascalCase(scaffoldName);
      if (substring === '$$camelName$$') return toCamelCase(scaffoldName);
    })

}

export function transformFilename(scaffoldName, filename) {
  return transformName(scaffoldName, filename);
}

export function transformContents(scaffoldName, contents, fileName) {
  return transformName(scaffoldName, contents);
}

meteor login

Logs you in to your Meteor developer account.

Usage:

bash
meteor login [--email]

Details:

  • Prompts for your username and password
  • Pass --email to log in by email address rather than by username
  • You can set METEOR_SESSION_FILE=token.json before meteor login to generate a login session token, avoiding the need to share credentials with third-party service providers

meteor logout

Logs you out of your Meteor developer account.

Usage:

bash
meteor logout

meteor whoami

Displays your currently logged-in username.

Usage:

bash
meteor whoami

meteor deploy site

Deploys the project in your current directory to Galaxy.

Basic Deployment

bash
meteor deploy your-app.meteorapp.com

Deployment Options

OptionDescription
--delete, -DPermanently delete this deployment
--debugDeploy in debug mode (don't minify, etc.)
--settings, -s <file>Set optional data for Meteor.settings
--freeDeploy as a free app (with limitations)
--mongoCreate and connect to a free shared MongoDB database
--plan <plan>Set app plan: professional, essentials, or free
--container-size <size>Set container size: tiny, compact, standard, double, quad, octa, or dozen
--ownerSpecify organization or user account to deploy to
--cache-buildReuse the build if the git commit hash is the same
--allow-incompatible-updateAllow packages to be upgraded or downgraded to potentially incompatible versions
--deploy-polling-timeout <ms>Time to wait for build/deploy (defaults to 15 minutes)
--no-waitExit after code upload instead of waiting for deploy to complete

Free Deployment

Deploy a free app with MongoDB using:

bash
meteor deploy your-app.meteorapp.com --free --mongo

Quick Start

The combination of --free and --mongo is the fastest way to deploy an app without any additional configuration.

Free App Limitations

  • Domain: Must use a Meteor domain (.meteorapp.com, .au.meteorapp.com, or .eu.meteorapp.com)
  • Cold Start: App stops after 30 minutes of inactivity and restarts on next connection
  • Resources: Limited to one Tiny container (not recommended for production use)

MongoDB Options

Shared MongoDB (Free)

The --mongo option creates a database in Galaxy's shared cluster:

  • On first deploy, you'll receive your MongoDB URI in the console
  • The URI is also visible in your app's version details in Galaxy
  • You must create at least one document to fully instantiate the database
  • The database can be accessed using any MongoDB client with the provided URI

WARNING

Free shared MongoDB is not recommended for production applications. The shared cluster doesn't provide backups or restoration resources.

MongoDB Connection Settings

When connecting to the free MongoDB shared cluster using your own settings, include:

json
{
  "packages": {
    "mongo": {
      "options": {
        "tlsAllowInvalidCertificates": true
      }
    }
  }
}
Why is this needed?

This is necessary because the database provider doesn't have certificates installed on every machine. More about this option here.

Important Notes

  • Settings persist between deployments unless explicitly changed
  • Your project should be a git repository (commit hash is used to track code changes)
  • Free apps and MongoDB shared hosting are not recommended for production use
  • Meteor Software reserves the right to stop or remove applications that abuse the free plan

Version Compatibility

  • --free and --mongo options were introduced in Meteor 2.0
  • --plan option was introduced in Meteor 2.1
  • --container-size option was introduced in Meteor 2.4.1
  • --cache-build option is available since Meteor 1.11

meteor update

Updates your Meteor application while maintaining compatibility.

Usage:

bash
meteor update
meteor update --patch
meteor update --release <release>
meteor update --packages-only
meteor update [packageName packageName2 ...]
meteor update --all-packages

Update Types:

CommandDescription
meteor updateUpdates the Meteor release and compatible package versions
meteor update --patchUpdates to the latest patch release (recommended for bug fixes)
meteor update --release <release>Updates to a specific Meteor release
meteor update --packages-onlyUpdates only packages, not the Meteor release
meteor update [packageName ...]Updates specific named packages
meteor update --all-packagesUpdates all packages including indirect dependencies

Important Notes:

  • Every project is pinned to a specific Meteor release
  • By default, updates will not break compatibility between packages
  • Patch releases contain minor, critical bug fixes and are highly recommended
  • The --release flag can override compatibility checks (may cause warnings)
  • The --all-packages option will update all packages to their latest compatible versions, respecting dependency constraints

meteor add package

Adds packages to your Meteor project.

Usage:

bash
meteor add [package1] [package2] ...
meteor add package@version

Version Constraints:

  • package@1.1.0 - Version 1.1.0 or higher (but not 2.0.0+)
  • package@=1.1.0 - Exactly version 1.1.0
  • package@=1.0.0 || =2.0.1 - Either version 1.0.0 or 2.0.1 exactly

Notes:

  • By convention, community packages include the maintainer's name (e.g., iron:router)
  • To remove a version constraint, run meteor add package without specifying a version

meteor remove package

Removes a package previously added to your Meteor project.

Usage:

bash
meteor remove [package1] [package2] ...

Notes:

  • For a list of currently used packages, run meteor list
  • This removes the package entirely (to only remove version constraints, use meteor add)
  • Transitive dependencies aren't automatically downgraded unless necessary

meteor list

Lists all packages added to your project, including versions and available updates.

Usage:

bash
meteor list [flags]

Flags:

FlagDescription
--treeOutputs a tree showing package reference hierarchy
--jsonOutputs an unformatted JSON string of package references
--weakShows weakly referenced dependencies (only with --tree or --json)
--detailsAdds more package details (only with --json)

meteor add-platform platform

Adds platforms to your Meteor project.

Usage:

bash
meteor add-platform [platform1] [platform2] ...

Notes:

  • Multiple platforms can be added with one command
  • After adding, use meteor run <platform> to run on that platform
  • Use meteor build to build for all added platforms

meteor remove-platform platform

Removes a previously added platform.

Usage:

bash
meteor remove-platform [platform]

Notes:

  • For a list of currently added platforms, use meteor list-platforms

meteor list-platforms

Lists all platforms explicitly added to your project.

Usage:

bash
meteor list-platforms

meteor ensure-cordova-dependencies

Checks if dependencies are installed, and installs them if necessary.

Usage:

bash
meteor ensure-cordova-dependencies

meteor mongo

Opens a MongoDB shell on your local development database.

Usage:

bash
meteor mongo

WARNING

For now, you must already have your application running locally with meteor run. This will be easier in the future.

meteor reset

Resets the current project to a fresh state and clears the local cache.

Usage:

bash
meteor reset [--db]

Flags:

  • --db - Also removes the local MongoDB database

WARNING

Reset with --db flag 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 show collections and db.<collection>.find() to inspect your data.

WARNING

For now, you cannot run this while a development server is running. Quit all running meteor applications before running this.

meteor build

Package your project for deployment.

bash
meteor build <output-path> [options]

Output Artifacts

The command produces deployment-ready artifacts for all platforms in your project:

  • Server Bundle: A tarball containing everything needed to run the application server
  • Android Package: AAB/APK bundle and Android project source (if Android platform is added)
  • iOS Package: Xcode project source (if iOS platform is added)

Self-Hosting

You can use the server bundle to host a Meteor application on your own infrastructure instead of Galaxy. Note that you'll need to handle logging, monitoring, backups, and load-balancing yourself.

Options

OptionDescription
--debugBuild in debug mode (don't minify, preserve source maps)
--directoryOutput a directory instead of a tarball (existing output location will be deleted first)
--server-onlySkip building mobile apps but still build the 'web.cordova' client target for hot code push
--mobile-settings <file>Set the initial value of Meteor.settings in mobile apps
--server <url>Location where mobile builds connect to the Meteor server (defaults to localhost:3000)
--architecture <arch>Build for a different architecture than your development machine
--allow-incompatible-updateAllow packages to be upgraded/downgraded to potentially incompatible versions
--platforms <platforms>Build only for specified platforms (when available)
--packageType <type>Choose between apk or bundle for Android builds (defaults to bundle)
Available Architectures

Valid architectures include:

  • os.osx.x86_64
  • os.linux.x86_64
  • os.linux.x86_32
  • os.windows.x86_32
  • os.windows.x86_64

This option selects the architecture of binary-dependent Atmosphere packages. If your project doesn't use Atmosphere packages with binary dependencies, --architecture has no effect.

Examples

bash
# Basic build
meteor build ../build

# Output a directory instead of a tarball
meteor build ../build --directory

# Debug build (unminified)
meteor build ../build --debug

# Build only the server (skip mobile apps)
meteor build ../build --server-only

# Build for specific platforms
meteor build ../build --platforms=android,ios

# Set server location for mobile apps
meteor build ../build --server=https://example.com:443

# Build for a different architecture
meteor build ../build --architecture=os.linux.x86_64

# Specify Android package type
meteor build ../build --packageType=apk

meteor lint

Run linters on your Meteor application code.

bash
meteor lint [options]

Description

This command:

  • Performs a complete build of your application
  • Runs all configured linters
  • Outputs build errors and linting warnings to standard output

CI Integration

The meteor lint command is particularly useful for continuous integration environments to catch code quality issues before deployment.

Options

OptionDescription
--allow-incompatible-updateAllow packages to be upgraded or downgraded to potentially incompatible versions if required to satisfy all package version constraints

Example Usage

bash
# Basic usage
meteor lint

# Allow incompatible package updates during linting
meteor lint --allow-incompatible-update

WARNING

Linting errors will prevent your application from being built successfully. Fixing these errors is required for deployment.

meteor search

Search for Meteor packages and releases.

bash
meteor search <regex> [options]

Description

Searches through the Meteor package and release database for items whose names match the specified regular expression.

Default Behavior

By default, the search will not show:

  • Packages without official versions (e.g., those with only prereleases)
  • Packages known to be incompatible with Meteor 0.9.0 and later due to migration issues

Options

OptionDescription
--maintainer <username>Filter results by authorized maintainer
--show-allShow all matches, including prereleases and incompatible packages
--ejsonDisplay more detailed output in EJSON format

Examples

bash
# Search for all packages related to "auth"
meteor search auth

# Search for packages maintained by a specific user
meteor search mongo --maintainer meteor

# Show all matching packages, including prereleases
meteor search bootstrap --show-all

# Get detailed output in EJSON format
meteor search react --ejson

Advanced Searching

You can use regular expressions for more powerful searches:

bash
# Packages that start with "react-"
meteor search "^react-"

# Packages that end with "router"
meteor search "router$"

meteor show

Display detailed information about packages and releases.

bash
meteor show <name> [options]
meteor show <name@version> [options]
meteor show [options]

Description

Shows detailed information about a specific package or release, including:

  • Name and summary
  • Available versions
  • Maintainers
  • Homepage and git URL (if specified)
  • Exports and other package metadata

TIP

This works on both local packages built from source and remote packages stored on the server.

Common Usage

View Package Information

bash
# Show information about a package
meteor show jam:easy-schema

# Show information about a specific version
meteor show jam:easy-schema@1.7.0

# Show information about the local version
meteor show jam:easy-schema@local

View Meteor Releases

bash
# Show recommended Meteor releases
meteor show METEOR

# Show all Meteor releases (including intermediate ones)
meteor show METEOR --show-all

Options

OptionDescription
--show-allShow hidden versions, experimental releases, and incompatible packages
--ejsonDisplay more detailed output in EJSON format

Examples

bash
# Running from a package directory shows info for that package
cd ~/my-package
meteor show

# View detailed EJSON output
meteor show react-meteor-data --ejson

Default Behavior

By default, Meteor:

  • Shows no more than five versions
  • Hides experimental release versions
  • Hides packages incompatible with Meteor 0.9.0 and later
Version Selection

For version-specific information (like exports), Meteor will use:

  1. The local version, if available
  2. The latest official version, if no local version exists

meteor publish

Publish a package to Atmosphere (Meteor package server).

bash
meteor publish [options]
meteor publish --update

Description

Publishes a new version of a local package to Atmosphere. Must be run from the package directory.

Package Naming Convention

Published package names must begin with the maintainer's Meteor Developer Account username and a colon, like username:package-name.

Common Operations

Publish a New Package

bash
cd my-package
meteor publish --create

Update an Existing Package

bash
cd my-package
meteor publish

Update Package Metadata

Update README, description, or other metadata without changing the code:

bash
cd my-package
meteor publish --update

Options

OptionDescription
--createPublish a new package for the first time
--updateUpdate metadata of a previously published version (README, git URL, description, etc.)
--allow-incompatible-updateAllow dependencies to be upgraded/downgraded to potentially incompatible versions
--no-lintSkip linting the package and its local dependencies before publishing

Architecture-Specific Packages

For packages with binary components:

  • Regular publish will only upload the build for your current architecture
  • Use meteor publish-for-arch from a different machine to upload builds for other architectures
Package Publication Process

When you publish a package:

  1. Meteor reads version information from package.js
  2. Builds the package
  3. Sends both source code and built version to the package server
  4. Marks you as the sole maintainer (use meteor admin maintainers to modify)

Examples

bash
# Publish a new package
meteor publish --create

# Update an existing package
meteor publish

# Update metadata only
meteor publish --update

# Publish without linting
meteor publish --no-lint

TIP

Use meteor show to preview how your package information will appear in the package server.

meteor publish-for-arch

Publish architecture-specific builds of a package.

bash
meteor publish-for-arch packageName@version

Description

Creates and publishes a build of an existing package version for a different architecture than the one initially published.

Architecture Support

Meteor currently supports the following architectures:

  • 32-bit Linux
  • 64-bit Linux (used by Galaxy servers)
  • 64-bit macOS

Use Case

When a package contains platform-specific components (like npm modules with native code), running meteor publish only creates a build for your current architecture. To make your package usable on other architectures, you need to run publish-for-arch from machines with those architectures.

How It Works

  1. Run the command on a machine with the target architecture
  2. Meteor downloads your package's source and dependencies from the package server
  3. Builds the package for the current architecture
  4. Uploads the architecture-specific build to the package server

No Source Required

You don't need to have a copy of your package's source code to run this command. Meteor automatically downloads everything needed from the package server.

Example Workflow

Imagine you've published a package with binary components from a Mac:

bash
# On your Mac
cd my-binary-package
meteor publish --create

To make it available for Linux users:

bash
# Later, on a 64-bit Linux machine
meteor publish-for-arch username:my-binary-package@1.0.0

meteor publish-release

Publish a new Meteor release.

bash
meteor publish-release <path-to-json-config> [options]

Description

Publishes a new release of Meteor based on a JSON configuration file. This allows you to create custom Meteor releases or release tracks.

Release Tracks

Meteor releases are divided into tracks:

  • Only Meteor Software can publish to the default Meteor track
  • Anyone can create and publish to their own custom tracks
  • Users won't switch tracks when running meteor update unless specified

Configuration File Format

The JSON configuration file must contain:

json
{
  "track": "TRACK_NAME",          // Release track (e.g., "METEOR")
  "version": "VERSION",           // Version number (e.g., "2.8.0")
  "recommended": true|false,      // Is this a recommended release?
  "description": "DESCRIPTION",   // Brief description of the release
  "tool": "PACKAGE@VERSION",      // The meteor tool package and version
  "packages": {                   // Specific package versions for this release
    "package1": "version",
    "package2": "version"
  },
  "patchFrom": ["VERSION1", "VERSION2"]  // Optional: releases this patches
}

Prerequisites

You must publish all package versions to the package server before you can specify them in a release.

Options

OptionDescription
--create-trackCreate and publish a new release track
  • Set recommended: true for stable releases (e.g., METEOR@3.2.2)
  • Set recommended: false for release candidates, experimental releases, etc.

Patch Releases

Use the patchFrom field to specify a patch release:

  • Lists releases this new release patches
  • Automatically unrecommends the releases specified in patchFrom

Examples

Publishing a New Release Track

bash
meteor publish-release my-release-config.json --create-track

Publishing a New Release

bash
meteor publish-release meteor-3.3.0.json

Sample Configuration File

json
{
  "track": "MYCORP",
  "version": "1.0.0",
  "recommended": true,
  "description": "MyCompany's custom Meteor release",
  "tool": "meteor-tool@2.8.0",
  "packages": {
    "accounts-base": "2.2.5",
    "mongo": "1.15.0"
  }
}

Custom Tool Forks

This system allows forks of the meteor tool to be published as packages, letting users switch to custom tool implementations by changing to the corresponding 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.

meteor npm

The meteor npm command calls the npm version bundled with Meteor itself.

Additional parameters can be passed in the same way as the npm command (e.g. 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 lodash from npm to your node_modules directory and save its usage in your package.json file.

Using the 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 bcrypt) because doing so ensures that they are built using the same libraries.

Additionally, this access to the npm that comes with Meteor avoids the need to download and install npm separately.

meteor node

The 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 shell will 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 Read-Eval-Print-Loop (REPL) interface and allow you to interactively run JavaScript and see the results.

Executing meteor node -e "console.log(process.versions)" would run console.log(process.versions) in the version of node bundled with Meteor.