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 {#meteorhelp}

Get help on meteor command line usage.

meteor help

Lists the common meteor commands.

meteor help <command>

Prints detailed help about the specific command.

meteor run {#meteorrun}

Run a meteor development server in the current project.

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

Node.js Options

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

Windows PowerShell:

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

Linux/macOS:

SERVER_NODE_OPTIONS=--inspect-brk meteor run

Port Configuration Example

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 {#meteordebug}

Run the project with the server process suspended for debugging.

::: warning 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

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

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

Command Usage

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

::: details 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:

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

meteor profile {#meteorprofile}

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

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

::: info 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

::: info All other options from meteor run are also supported (e.g., --settings, --exclude-archs). If you use the --build option, it also accepts meteor build flags (e.g. --mobile-settings, --architecture). :::

Environment Variables

::: 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

# Basic profile
meteor profile

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

# Monitor build time
meteor profile --build

# 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

::: details 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. The same applies to the --build option, which matches meteor build options. :::

meteor create app-name {#meteorcreate}

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

meteor create [options] app-name

::: tip Default Behavior Without any flags, meteor create app-name generates a React project. :::

::: tip 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:

  ~ 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

Application Types

Project Structure Options

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

Included Packages

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

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

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

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

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

::: tip File Structure To learn more about the recommended file structure for Meteor apps, check the Meteor Guide. :::

meteor generate {meteorgenerate}

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:

meteor generate customer

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

That will have the following code:

collection.js {meteorgenerate-collection.js}

import { Mongo } from 'meteor/mongo';

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

methods.js {meteorgenerate-methods.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 {meteorgenerate-publication.js}

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

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

index.js {meteorgenerate-index.js}

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

path option {meteorgenerate-path}

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.

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

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

collection.ts {meteorgenerate-collection.ts}

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 {meteorgenerate-methods.ts}

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 {meteorgenerate-publications.ts}

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

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

index.ts {meteorgenerate-index.ts}

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

Using the Wizard {meteorgenerate-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.

meteor generate

Using your own template {meteorgenerate-templating}

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

meteor generate feed --templatePath=/scaffolds-ts

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? {meteorgenerate-template-rename}

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.

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? {meteorgenerate-template-faq}

--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

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:

 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:

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:

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:

meteor logout

meteor whoami

Displays your currently logged-in username.

Usage:

meteor whoami

meteor deploy site {#meteordeploy}

Deploys the project in your current directory to Galaxy.

Basic Deployment

meteor deploy your-app.meteorapp.com

Deployment Options

Free Deployment

Deploy a free app with MongoDB using:

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

::: tip 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:

{
  "packages": {
    "mongo": {
      "options": {
        "tlsAllowInvalidCertificates": true
      }
    }
  }
}

::: details 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

::: info 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:

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

Update Types:

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 {#meteor-add}

Adds packages to your Meteor project.

Usage:

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

Version Constraints:

• [email protected] - 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 {#meteor-remove}

Removes a package previously added to your Meteor project.

Usage:

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 {#meteor-list}

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

Usage:

meteor list [flags]

Flags:

meteor add-platform platform {#meteor-add-platform}

Adds platforms to your Meteor project.

Usage:

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 {#meteor-remove-platform}

Removes a previously added platform.

Usage:

meteor remove-platform [platform]

Notes:

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

meteor list-platforms {#meteor-list-platforms}

Lists all platforms explicitly added to your project.

Usage:

meteor list-platforms

meteor ensure-cordova-dependencies {#meteor-ensure-cordova-dependencies}

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

Usage:

meteor ensure-cordova-dependencies

meteor mongo {#meteor-mongo}

Opens a MongoDB shell on your local development database.

Usage:

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 {#meteor-reset}

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

Usage:

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 {#meteorbuild}

Package your project for deployment.

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)

::: tip 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

::: details 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

# 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 {#meteorlint}

Run linters on your Meteor application code.

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

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

Options

Example Usage

# 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 {#meteorsearch}

Search for Meteor packages and releases.

meteor search <regex> [options]

Description

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

::: info 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

Examples

# 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

::: tip Advanced Searching You can use regular expressions for more powerful searches:

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

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

:::

meteor show {#meteorshow}

Display detailed information about packages and releases.

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

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

# Show information about a specific version
meteor show jam:[email protected]

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

View Meteor Releases

# Show recommended Meteor releases
meteor show METEOR

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

Options

Examples

# 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

::: info 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 :::

::: details 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 {#meteorpublish}

Publish a package to Atmosphere (Meteor package server).

meteor publish [options]
meteor publish --update

Description

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

::: warning 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

cd my-package
meteor publish --create

Update an Existing Package

cd my-package
meteor publish

Update Package Metadata

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

cd my-package
meteor publish --update

Options

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

::: details 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

# 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 {#meteorpublishforarch}

Publish architecture-specific builds of a package.

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.

::: info 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

::: tip 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:

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

To make it available for Linux users:

# Later, on a 64-bit Linux machine
meteor publish-for-arch username:[email protected]

meteor publish-release {#meteorpublishrelease}

Publish a new Meteor release.

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.

::: info 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:

{
  "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
}

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

Options

Recommended Flag

• Set recommended: true for stable releases (e.g., [email protected])
• 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

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

Publishing a New Release

meteor publish-release meteor-3.3.0.json

Sample Configuration File

{
  "track": "MYCORP",
  "version": "1.0.0",
  "recommended": true,
  "description": "MyCompany's custom Meteor release",
  "tool": "[email protected]",
  "packages": {
    "accounts-base": "2.2.5",
    "mongo": "1.15.0"
  }
}

::: tip 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 {#meteortestpackages}

Run tests for Meteor packages.

meteor test-packages [options] [package...]

Description

Runs unit tests for one or more packages. Test results appear in a browser dashboard that updates whenever relevant source files are modified.

::: tip Package Specification Packages can be specified by:

• Name: Resolved using the standard package search algorithm
• Path: Any argument containing a '/' is loaded from that directory path :::

If no packages are specified, all available packages will be tested.

Options

Mobile Testing Options

Examples

Test specific packages by name

meteor test-packages accounts-base accounts-password

Test a package by path

meteor test-packages ./packages/my-package

Test with custom settings

meteor test-packages --settings settings.json

Test with Mocha test driver

meteor test-packages --driver-package meteortesting:mocha

Test with filter

meteor test-packages --filter myTestName

Alternatively, you can use the TINYTEST_FILTER environment variable to filter:

TINYTEST_FILTER=myTestName meteor test-packages

Test on mobile device

meteor test-packages --ios-device

meteor admin {#meteoradmin}

Administrative commands for official Meteor services.

meteor admin <command> [args]

::: warning Authorization Required These commands require authorization to use. :::

Available Commands

Usage Examples

# View or change package maintainers
meteor admin maintainers packagename [add/remove] [username]

# Change a package homepage
meteor admin change-homepage packagename [url]

# List your organizations
meteor admin list-organizations

# Manage organization members
meteor admin members organization-name [add/remove] [username]

::: tip Detailed Help For more information on any admin command, run:

meteor help admin <command>

:::

meteor shell {#meteorshell}

Start an interactive JavaScript shell for evaluating server-side code.

meteor shell

Description

The meteor shell command connects to a running Meteor server and provides an interactive JavaScript REPL (Read-Eval-Print Loop) for executing server-side code.

::: tip Connection Behavior

• Requires a running Meteor server in the application directory
• If no server is available, it will keep trying to connect until successful
• Multiple shells can be attached to the same server simultaneously :::

Features

Server Integration

• Exiting the shell does not terminate the server
• If the server restarts (due to code changes or errors), the shell will automatically restart with it
• You can manually trigger a reload by typing .reload in the shell

Developer Experience

Example Usage

# Start a Meteor server in one terminal
meteor run

# Connect a shell in another terminal
meteor shell

# Now you can run server-side code interactively:
> Meteor.users.find().count()
> Package.mongo.Mongo.Collection.prototype
> Meteor.isServer
true
> .reload  # Manually restart the shell

::: details Advanced Example

// Query the database
> db = Package.mongo.MongoInternals.defaultRemoteCollectionDriver().mongo.db
> db.collection('users').find().toArray()

// Access Meteor settings
> Meteor.settings.public

// Inspect publications
> Object.keys(Meteor.server.publish_handlers)

:::

meteor npm {#meteornpm}

Run npm commands using Meteor's bundled npm version.

meteor npm <command> [args...]

Description

The meteor npm command executes npm commands using the version bundled with Meteor itself.

::: tip Benefits of Using Meteor's npm

1. Ensures compatibility with Meteor's Node.js version
2. Crucial for packages with native dependencies (like bcrypt)
3. No need to install npm separately
4. Consistent behavior across development environments :::

Common Commands

Examples

# Install a package and save to dependencies
meteor npm install lodash --save

# Install packages from package.json
meteor npm install

# Run an npm script defined in package.json
meteor npm run start

# View package information
meteor npm info react

::: warning Native Dependencies Using meteor npm instead of regular npm is especially important when working with packages that have binary dependencies making native C calls (like bcrypt). This ensures they're built with the same libraries used by Meteor. :::

meteor node {#meteornode}

Run Node.js commands using Meteor's bundled Node.js version.

meteor node [options] [script.js] [arguments]

::: info Alternative Consider using meteor shell instead, which provides similar functionality plus access to your Meteor application's server context. :::

Description

The meteor node command runs Node.js using the version bundled with Meteor itself.

Common Uses

Examples

# Start an interactive REPL
meteor node

# Execute inline JavaScript
meteor node -e "console.log(process.versions)"

# Run a script with arguments
meteor node scripts/migrate.js --force

# Check installed Node.js version
meteor node --version

::: details Running a Simple Script Create hello.js:

console.log('Hello from Node.js version', process.version);
console.log('Arguments:', process.argv.slice(2));

Run it:

meteor node hello.js arg1 arg2

:::