Introducing Environments for Mastra Platform

You can now deploy the same project to production, staging, and preview environments each with its own URL, variables, and database.

Joel SmithJoel Smith·

Jul 22, 2026

·

3 min read

One of the oldest patterns in shipping software is to test production-like deployments in a test or staging environment. Now, with Environments on the Mastra platform, you can spin up multiple environments for your projects to make testing your Mastra apps even easier.

Environments also bundle Studio and Server into a single deployment command for even easier deployments. Just run mastra deploy.

Every Mastra platform project can now run multiple environments. You can create and manage environments for your project in the platform or via the CLI. When you create a project, your first deploy automatically creates a production environment. From the CLI, running mastra env create <env_name> gives you a new deploy target inside the same project with its own URL, environment variables, deploy history, and optionally, its own hosted database and workspace.

Until now, projects on the platform were by default single environments. If you wanted to test a change before your users saw it, you either deployed over production and hoped, or you stood up a duplicate project and hand-copied every variable into it. But now, you can share environment variables between multiple environments and safely test changes before shipping to production.

Environments can also pin resources to specific geographic regions. You can create separate production environments for users in different geographic regions and use a load balancer to send traffic based on a user’s location. Use regional deployments to colocate resources like your app server, database, and observability pipeline close to your users for optimal performance.

Each environment is isolated along four lines:

  • Its own URL. Run experiments in your staging Studio. Route traffic to your production Server. Mix-and-match as needed.
  • Its own variables. Use variables scoped to environments or across multiple environments.
  • Optionally, its own database. Share a managed LibSQL or Postgres Database across multiple environments or deploy a database for each environment.

Requirements

Environment-based deploys require version 1.44 or higher of @mastra/core. For older projects, we’ll continue to support the legacy deployment flows through mastra server deploy and mastra studio deploy for the next 90 days, and you should expect to see a deprecation notice in your deployment flow during that time period,

Adding multiple environments is currently limited to the Team and Enterprise plans.

Get started in the CLI

From your project directory, create an environment and deploy to it — or skip the first command and let the deploy offer to create it for you.

The first deploy creates a production environment:

GNU BashTerminal
mastra deploy

Create a new environment:

GNU BashTerminal
mastra env create staging

Deploy to a specific environment:

GNU BashTerminal
mastra deploy --env staging

To create an environment in a specific region, pass --region at creation. Currently us and eu are supported:

GNU BashTerminal
mastra env create eu-preview --type preview --region eu

Then check what's running where:

GNU BashTerminal
mastra env list

The output shows each environment's name, region, active deploy status, and managed variables. Pass --json for CI.

For more information and full configuration options, read our updated platform docs on environments and deploys.

Share:
Joel Smith
Joel SmithHead of Platform

Joel Smith is the Head of Platform at Mastra, leading product and engineering efforts around the entire Mastra platform. A high school English teacher turned software engineer turned product/engineering manager, he previously led product and engineering teams in early stage startups focused on blockchain data, incident management and developer tools infrastructure.

All articles by Joel Smith