In Postman, you switch environments from a dropdown. In Newman, you pass the environment file as a flag. Same concept. Different interface.
# Run with a specific environment
newman run collections/my-api-tests.postman_collection.json \
-e environments/dev.postman_environment.json
# Short form: -e is the same as --environment
newman run collections/my-api-tests.postman_collection.json \
--environment environments/staging.postman_environment.jsonWant to run the same tests against dev and staging? Two commands. Same collection. Different environment file.
# Run against dev
newman run collections/api-tests.postman_collection.json \
-e environments/dev.postman_environment.json
# Run against staging
newman run collections/api-tests.postman_collection.json \
-e environments/staging.postman_environment.json
# Run against production (smoke test — read-only tests only!)
newman run collections/api-tests.postman_collection.json \
-e environments/prod.postman_environment.json \
--folder "Smoke Tests"Be very careful running tests against production. Only run read-only tests (GET requests). If your collection has POST/PUT/DELETE requests that create or modify data, use the --folder flag to run only the safe folder. One wrong test run against prod can create garbage data or worse.
Remember how Current Values are not exported? In CI/CD, you need to inject secrets at runtime. The --env-var flag lets you override or add variables without editing the environment file.
# Override a single variable
newman run collections/api-tests.postman_collection.json \
-e environments/staging.postman_environment.json \
--env-var "authToken=eyJhbGciOiJIUzI1NiJ9.secret.token"
# Override multiple variables
newman run collections/api-tests.postman_collection.json \
-e environments/staging.postman_environment.json \
--env-var "authToken=$AUTH_TOKEN" \
--env-var "apiKey=$API_KEY" \
--env-var "adminEmail=$ADMIN_EMAIL"
# Use CI environment variables (GitHub Actions syntax)
# In your workflow: env.AUTH_TOKEN is set from secrets
newman run collections/api-tests.postman_collection.json \
-e environments/staging.postman_environment.json \
--env-var "authToken=${{ secrets.AUTH_TOKEN }}"The --env-var flag overrides values from the environment file. If the file has baseUrl=https://www.testerrank.com and you pass --env-var "baseUrl=https://staging.api.com", the command-line value wins. This is perfect for CI/CD where you inject secrets at runtime.
If your collection uses only collection variables (no environment variables), you do not need the -e flag at all. You can also use --env-var to provide all values without any environment file.
# No environment file — inject everything via flags
newman run collections/api-tests.postman_collection.json \
--env-var "baseUrl=https://jsonplaceholder.typicode.com" \
--env-var "userId=1"# You can also pass a globals file
newman run collections/api-tests.postman_collection.json \
-e environments/staging.postman_environment.json \
-g globals.postman_globals.jsonQ: How do you pass sensitive data like API keys to Newman in a CI/CD pipeline?
A: Never put secrets in the environment JSON file — those get committed to git. Use the --env-var flag to inject secrets at runtime: newman run collection.json -e env.json --env-var "apiKey=$API_KEY". The $API_KEY comes from CI/CD secrets (GitHub Secrets, Jenkins credentials, etc.). This way, the secret lives in the CI platform, not in your code repository. You can override multiple variables with multiple --env-var flags.
Key Point: Use -e to pass environment files. Use --env-var to inject or override secrets at runtime. Same collection, different environments = full coverage.