Blog/Announcements

Announcing Mastra 1.0!

Sam Bhagwat

Sam Bhagwat

·

Jan 20, 2026

Today, we’re excited to announce the release of Mastra 1.0 in stable.

Back in November, we cut our first 1.0 beta. Since then, hundreds of teams have been running it in production. That feedback resulted in 94 1.0-related fixes plus several new features that didn’t make the first cut, including server adapters and composite storage.

We stabilized APIs, simplified deployment, improved observability, and addressed production issues.

Mastra 1.0 is the result of exceptional work by a talented team: Ward Peeters, Tony Kovanen, Tyler Barnes, Marvin Franchet, Eric Pinzur, Ehindero Israel, Greg Lobinski, Caleb Barnes, Daniel Lew, Taofeeq Oloderu, Nik Aiyer, Yujohn Nattrass, Lennart Jorgens, my co-founders Abhi Ayer and Shane Thomas, and our open source contributors.

This is also a good time to reflect on where we’ve come. We started working on Mastra in October 2024. But we’ve worked together in open-source, at Gatsby and elsewhere, for the better part of a decade.

None of us have seen anything like this.

As measured by npm downloads, in these 15 months, Mastra has had growth from the first 5 years of Gatsby. We’re being used in production by companies like Replit, PayPal, Sanity, Marsh McLennan, Range, Counsel Health.

Teams are using Mastra to power SaaS in-app chat, SRE and dev productivity agents, B2C vertical agents, agentic enterprise search, and AI-ify internal business processes.

So let’s dig in:

What’s new in 1.0?

Between the beta and today, we focused on changes that materially improve how Mastra runs in production. The result is a smaller set of foundational upgrades that simplify deployment, make system behavior more explicit, and give you finer control over agents, workflows, storage, and observability.

Key changes in 1.0 include:

In addition to the new features in 1.0, there are a handful of changes that affect existing projects. Most are mechanical renames or structural cleanups, and the migration guide and codemods cover the majority of the work.

Server Adapters

The biggest architectural shift in 1.0 is how Mastra is deployed.

Previously, mastra build bundled your project with esbuild. This worked well in many cases, but became harder to manage in monorepos, with workspace dependencies, and when native modules were involved.

Server Adapters remove that overhead. Mastra wraps your existing Express or Hono server instead of requiring a bundling step

 1import express from "express";
 2import { MastraServer } from "@mastra/express";
 3import { mastra } from "./mastra";
 4
 5const app = express();
 6const server = new MastraServer({ app, mastra });
 7await server.init();
 8
 9app.listen(3001);

Agents, workflows, and tools are exposed as endpoints on the server you already run, while preserving your existing TypeScript configuration, monorepo structure, middleware, and deployment pipeline.

Standalone deployments via mastra build remain supported, but Server Adapters are now the recommended approach for most teams.

Read more about the benefits of Server adapters here: Announcing Server Adapters: Run Mastra Inside Your Existing Express or Hono App.

Composite storage

Mastra 1.0 introduces per-domain storage configuration, replacing the single-storage model.

Previously, Mastra used one storage backend for all domains, which coupled unrelated workloads. Composite storage lets each domain use the storage backend that fits its requirements.

 1import { MastraCompositeStore } from '@mastra/core/storage';
 2import { MemoryLibSQL, WorkflowsPG, ScoresPG } from '@mastra/pg';
 3
 4const storage = new MastraCompositeStore({
 5  id: 'composite',
 6  domains: {
 7    memory: new MemoryLibSQL({ url: 'file:./local.db' }),
 8    workflows: new WorkflowsPG({ connectionString: process.env.DATABASE_URL }),
 9    scores: new ScoresPG({ connectionString: process.env.DATABASE_URL }),
10  },
11});

Composite storage lets you use Postgres for workflows, LibSQL for memory, ClickHouse for observability data, or align each domain with existing databases. This keeps cost, latency, and scaling tradeoffs scoped to the domains that need them.

Single-storage configurations remain supported, with composite storage recommended for production deployments.

Read more about the advantages of using composite storage here: Composite Storage: Optimize for Performance, Scale and Cost with MastraStorage.

AI SDK v6 support

Mastra 1.0 adds full support for AI SDK v6, including LanguageModelV3 models and ToolLoopAgent.

Previously, Mastra supported AI SDK v5 (LanguageModelV1/V2). As v6 introduced LanguageModelV3 with a different API, Mastra needed updates to support the latest SDK.

You can now use LanguageModelV3 models and ToolLoopAgent directly:

 1import { openai } from '@ai-sdk/openai';
 2import { ToolLoopAgent } from 'ai';
 3import { Mastra } from '@mastra/core';
 4
 5const toolLoopAgent = new ToolLoopAgent({
 6  model: openai('gpt-4o'), // LanguageModelV3
 7  tools: { weather: weatherTool },
 8});
 9
10const mastra = new Mastra({
11  agents: { toolLoopAgent },
12});

V3's nested usage format is normalized to Mastra's flat format, with reasoning tokens and cached input tokens preserved. All existing V1 and V2 models continue to work unchanged—this is fully backward compatible.

Breaking changes

A small number of breaking changes were introduced in 1.0. The full list is covered in the 1.0 migration guide, and most updates are straightforward and handled by the codemods.

Breaking changes in 1.0 include:

  • The createTool execute signature changed to (inputData, context)
  • Imports were restructured to use subpath entry points (for example @mastra/core/agent, @mastra/core/tools)
  • Telemetry was moved to @mastra/observability
  • RuntimeContext was renamed to RequestContext
  • Collection accessors were renamed from .get* to .list*
  • Storage is now accessed through .getStore() domains
  • Memory defaults changed (semantic recall disabled, lastMessages set to 10)

You can run the codemods to handle most of these changes automatically:

 1npx @mastra/codemod@latest v1

Why 1.0 now?

Mastra has been running in production at scale for months. Teams at Replit, PayPal, Sanity, and Marsh McLennan have Mastra agents in production today, and Replit’s Agent 3 builds and runs Mastra agents at scale.

The broader adoption signals are now unambiguous. Mastra sees over 300k weekly npm downloads, has 19.3k GitHub stars, 300+ contributors, and a community of roughly 4,800 developers on Discord.

Over the beta period, community feedback directly shaped the final release. We tightened observability integrations across Langfuse, Braintrust, Arize, and LangSmith, fixed edge cases in nested workflows and streaming APIs, and resolved control-flow issues around .map and .foreach chaining, alongside many other smaller fixes.

After months of production usage and the fixes that followed, it was clear the APIs were ready to be locked and shipped as 1.0.

If you’re already using Mastra, thank you for the feedback that helped shape this release. If you’re new, this is the right place to start.

Get started with Mastra 1.0

Getting started with 1.0 depends on whether you're starting a new project or upgrading an existing one.

For new projects:

If you’re starting fresh, the Mastra CLI scaffolds a new 1.0 project with the recommended defaults.

 1npm create mastra@latest

For existing projects:

The codemod applies automated transformations across your codebase to update imports, API names, and method signatures for Mastra 1.0, leaving you with a clean diff to review instead of handling the migration manually.

 1npx @mastra/codemod@latest v1

For a more detailed walkthrough of the upgrade process, see the Upgrade to 1.0 documentation.