Skip to main content
The meteor run command (or just meteor) runs your Meteor project in local development mode.

Usage

Basic Usage

Run the app on localhost:3000:

Targets

If you have added mobile platforms to your app with meteor add-platform, you can specify run targets:
android
string
Run on the Android emulator
android-device
string
Run on a connected Android device
ios
string
Run on the iOS simulator
ios-device
string
Open Xcode with the iOS project for this app, where you can run your app on a connected iOS device

Examples

Options

--port
string
default:"3000"
Port to listen on (also uses port N+1 and a port specified by —app-port). Specify as --port=host:port to bind to a specific interface.
--open
boolean
default:"false"
Opens a browser window when the app starts
--inspect
string
Enable server-side debugging via debugging clients like the Node.js command-line debugger, Chrome DevTools, or Visual Studio Code. Optionally specify a port (default: 9229).
--inspect-brk
string
Enable server-side debugging with the server paused at startup, waiting for clients to attach. Optionally specify a port (default: 9229).
--mobile-server
string
Location where mobile builds connect to the Meteor server. Defaults to your local IP and the port that the Meteor server binds to. Can include a URL scheme (e.g., --mobile-server=https://example.com:443).
--cordova-server-port
number
Local port where Cordova will serve content. Important when multiple Cordova apps are built from the same Meteor app source code. By default, the port is generated using the id inside .meteor/.id.
--production
boolean
default:"false"
Simulate production mode. Minify and bundle CSS and JS files.
--raw-logs
boolean
default:"true"
Run without parsing logs from stdout and stderr
--timestamps
boolean
default:"false"
Run with timestamps in logs (same as passing --raw-logs=false)
--settings
string
Set optional data for Meteor.settings on the server. Provide a path to a JSON file.
--release
string
Specify the release of Meteor to use
--verbose
boolean
default:"false"
Print all output from build logs
--no-lint
boolean
default:"false"
Don’t run linters used by the app on every rebuild
--no-release-check
boolean
default:"false"
Don’t run the release updater to check for new releases
--allow-incompatible-update
boolean
default:"false"
Allow packages in your project to be upgraded or downgraded to versions that are potentially incompatible with the current versions, if required to satisfy all package version constraints.
--extra-packages
string
Run with additional packages (comma-separated, e.g., --extra-packages "package-name1, package-name2@1.2.3")
--exclude-archs
string
Don’t create bundles for certain web architectures (comma-separated, e.g., --exclude-archs "web.browser.legacy, web.cordova")

Examples

Run on a custom port:
Run with a settings file:
Run in production mode:
Warning: The --production flag should only be used to simulate production bundling for testing purposes. Use meteor build to create a bundle for production deployment. Run with debugging enabled:
Run and open in browser:
Run on Android emulator:
Run with specific mobile server URL:

Features

Auto-refresh

Whenever you change any of the application’s source files, the changes are automatically detected and applied to the running application.

Persistent Database

The application’s database persists between runs. It’s stored under the .meteor directory in the root of the project.

No Internet Required

No internet connection is required to run your app locally.

Debug Command

The meteor debug command is deprecated in favor of meteor --inspect-brk:

Debugging

The --inspect and --inspect-brk flags enable server-side debugging:
  • Use --inspect to enable debugging without pausing
  • Use --inspect-brk to pause at startup, waiting for debugger to attach
Two notable differences from Node.js behavior:
  1. The --inspect[-brk] flags affect the server process spawned by the build process, not the build process itself
  2. The --inspect-brk flag causes the server to pause just after server code loads but before it executes, giving you a chance to set breakpoints
You can also use the debugger keyword to set breakpoints: