Mastra vs Brahmalabs: a framework you code vs a platform you run

Two different purchases

Comparing Mastra and Brahmalabs feature-for-feature misses what you are actually buying. Mastra is an Apache-2.0 TypeScript framework: you write code, and the agent lives inside software you build, deploy, and operate. Brahmalabs is a managed platform: you define workflows, and the operation around them — approval routing, credential handling, sandboxing, audit — is the product. The real decision is whether the layer between working agent code and a system your security team will sign off on should be something you build or something you rent.

That framing is deliberately fair to Mastra, because a strong TypeScript team that picks it is genuinely well-served. The primitives are real, the license is clean, and the production users are named. What follows is an inventory of what the framework hands you and what remains on your plate — because that remainder is the entire case for a platform like Brahmalabs, and if the remainder is small for your team, you should not pay for it.

What Mastra gives you

Mastra was founded in 2024 by the creators of Gatsby.js and went through Y Combinator’s Winter 2025 batch. It has raised $35M — a $13M seed announced in October 2025 followed by a $22M Series A, with Spark Capital, Gradient, and Y Combinator among the investors. The core framework has been Apache-2.0 since July 9, 2025, when the team relicensed from the Elastic License v2 after enterprise-adoption friction; the GitHub repo declares a dual structure, with a separate Mastra Enterprise License covering the ee/ directories. Version 1.0 shipped stable on January 20, 2026.

The primitives are substantial, not marketing bullet points:

• Workflows as typed code. Steps are composed with createStep() and createWorkflow(), chained via .then() with branch and parallel control flow, with Zod-typed input/output schemas and configurable retries at step or workflow level.
• Suspend/resume as a real HITL primitive. A run can suspend with a payload and resume later; suspended state persists as a snapshot — including completed step outputs, execution path, and retry state — so a paused workflow survives deployments and restarts.
• A four-mechanism memory system. Message history, observational memory (background agents maintain a dense observation log), working memory, and semantic recall, keyed by resource and thread.
• Evals built in. A unified scorer factory with a four-step pipeline supporting both plain-function and LLM-as-judge steps, plus datasets and experiments.
• MCP in both directions. MCPClient connects agents to local or remote MCP servers; MCPServer exposes Mastra tools, agents, and workflows to any MCP client such as Cursor or Claude Desktop.
• Model routing. The Model Router reaches 600+ models from 40+ providers through a single provider/model string, with no per-provider SDK installs.
• Observability with pluggable exporters. AI-specific tracing exports to Langfuse, Braintrust, LangSmith, and OpenTelemetry-compatible backends, with multi-destination routing.

Adoption is not hypothetical. The 1.0 announcement names Replit (whose Agent 3 builds and runs Mastra agents), PayPal, Sanity, and Marsh McLennan as production users. Download figures conflict by source: Mastra self-reported 300k+ weekly npm downloads at the 1.0 launch in January 2026, while The Hacker News reported roughly 918,000 weekly downloads for @mastra/core in June 2026 — somewhere in that range is the truth.

If you stopped reading here, you would conclude Mastra is a complete answer. For some teams it is. The rest of this essay is about the teams for which it is not.

The build-surface inventory

A framework ends where operations begin. Here is the inventory: what Mastra ships, and what remains yours to build and run. Positions are as of July 2026.

Four of these rows deserve prose, because they are where self-assembly costs the most.

The approval surface

Mastra’s suspend/resume is the correct primitive, and the snapshot persistence is well-designed. But a primitive is not a product. The person approving a refund or a production deployment is usually not an engineer, and they will not resume a workflow by calling resumeStream(). Someone on your team builds the inbox, the notification path, the “what happens when the approver is on vacation” escalation, the N-of-M rule for decisions that need two sign-offs, and the timeout policy for approvals nobody answers. None of this is intellectually hard. All of it is time, and all of it must be maintained.

Credential isolation

In a self-assembled Mastra app, API keys live wherever your deployment puts environment variables, and the agent process can read them. That is normal for application code and uncomfortable for agents, because an agent’s inputs include text from the outside world. Building injection-resistant credential handling — short-lived scoped tokens, secrets resolved outside the agent’s context — is a security engineering project, not a configuration flag.

Sandboxing and egress

A framework cannot sandbox itself. If your agents execute code or browse, isolation boundaries, resource ceilings, and outbound network policy come from your infrastructure team: containers, network policy objects, DNS controls. This is exactly the kind of work platform teams are good at and product teams resent.

The audit trail

Mastra’s tracing answers “what did the agent do” for debugging. A compliance audit asks a different question: who changed this workflow, who approved this action, when did this credential get rotated — append-only, retained per policy, exportable. On the Mastra side that is either an Enterprise platform feature or a system you build against your own event store.

Brahmalabs: the operational layer as the product

Brahmalabs’ bet is that the right-hand column of that table is a product, not a per-company rebuild. Point by point:

• Durable execution is the substrate, not an add-on. Every run is a Temporal workflow under the hood; runs survive crashes, restarts, and partial outages, and a workflow that started yesterday can finish today. Pause, resume, and cancel are signals; approval waits do not burn compute.
• Approvals are a first-class node. Human-in-the-loop supports a single approver or N-of-M multi-party consensus, rejection policies, SLA timeouts, escalation chains, and dynamic approval forms. Approvals arrive in a reviewer inbox; the run parks durably until decided.
• Credential vaulting by design. Agents never see raw secrets — the vault injects short-lived, scoped references at call time, so even an exfiltrated prompt has nothing to leak.
• Sandboxing and egress control per run. Each agent step runs in an isolated container matched to the workload (browser, data, CI images) with CPU, memory, and timeout ceilings; images are digest-pinned. A DNS-plus-firewall sidecar enforces domain allowlists, and every run’s actual outbound domains are captured and shown on the run page.
• An audit trail auditors can use. An append-only log spans eight event categories — auth, config, run, HITL, integration, key, tenant, guardrail — queryable and exportable, with tier-based retention. Guardrail events are hash-chained.
• Customer data segregation at the data layer. Each customer gets an isolated database schema; queries physically cannot cross customers. Structural, not policy-based.
• MCP in both directions, with a governance twist. Bring any MCP server in — with activation validation, per-workflow allow-listing, and egress policy per server — and drive Brahmalabs itself from any MCP client. The Brahmalabs MCP server requires explicit human approval for every mutation; the LLM cannot self-approve.
• Bring your own model keys. Brahmalabs never marks up inference; the platform charges a flat fee per 1k tokens, and per-run cost in the UI is a labeled estimate, not exact metering.

Pricing is credit-metered by run and sandbox-minutes rather than seats: Free at $0 (1,000 credits, 5 workflows, 3 agents), Pro at $299/month (30,000 credits, SSO, multi-party approval, custom sandbox images, 90-day audit retention), Enterprise custom (dedicated compute, region choice, VPC peering, 1-year audit retention).

Now the honesty that the comparison requires. Brahmalabs is a young product: early access, no public case studies or customer logos, SOC 2 Type II in progress rather than certified, and no public status page. There is no self-hosted edition — on-prem or VPC is an Enterprise engagement, not a download. The integration catalog spans hundreds of actions across 300+ providers, but it is young and depth varies; Zapier and n8n are far ahead on breadth, with MCP servers closing some of the gap. There is no CLI, git-sync, or Terraform provider yet — workflows are versioned in-platform. Roles are three fixed tiers (admin, member, viewer) with no custom roles or SCIM. API and DSL docs live behind the dashboard login, not on a public portal. Mastra beats Brahmalabs on every one of those axes today.

Mastra Platform, three months in

Mastra knows the operational gap exists — the Mastra Platform launched April 9, 2026, three months before this writing, with three products: Studio (evals, logs, traces, datasets, an agent editor), Server (agents and workflows deployed as REST endpoints with OpenAPI docs), and Memory Gateway (hosted observational memory usable even outside the framework). Deploy is by CLI or GitHub push-to-deploy.

The pricing is usage-metered, not seat-based: Starter is $0/month with 100K observability events and 24 CPU hours included; Teams is $250/team/month with 1M events, 250 CPU hours, six-month retention, SSO, and SOC 2 documentation access. RBAC and audit logs arrive only at the custom-priced Enterprise tier, which also offers a self-hosted option with network policies and data-stays-in-your-VPC, priced as a flat annual fee. Persistent always-on servers cost $100/project on all tiers. Note the careful wording on compliance: the Teams tier grants access to SOC 2 documentation; Mastra does not claim certification on its pricing page, and neither should you on its behalf. Mastra publishes no per-run pricing and no data-residency regions as of July 2026.

Three months is not a criticism — every platform was three months old once, and the trajectory from framework to platform is the obvious one for a company that has raised $35M. But the published surface today is deployment, observability, evals, and memory. Neither the launch announcement nor the pricing page describes an approvals inbox, credential vaulting, per-step sandbox isolation, or egress policy as of July 2026. Those remain in the “yours to build” column even for Platform customers.

The June 2026 npm incident

On June 17, 2026, 145 npm packages in the @mastra/* namespace were compromised during an 88-minute window. Attackers hijacked the account of a former contributor whose publish access had never been revoked, and injected a trojanized clone of dayjs that installed a crypto-stealing RAT via a postinstall script. Microsoft attributed the attack to North Korea’s Sapphire Sleet group. Mastra’s response was fast and appropriate: the malicious versions were unpublished and the token-based permissions that bypassed MFA were removed.

The fair reading is not “Mastra is insecure.” Any popular npm namespace is a target, and an 88-minute exposure window with a same-incident policy fix is a good incident response. The fair reading is structural: when you self-assemble a production agent system from framework packages, the framework’s supply chain becomes your attack surface. Version pinning, provenance verification, postinstall-script policy, and contributor-access hygiene for every transitive dependency are now line items on your security program — for the agent framework specifically, because agent processes hold credentials and talk to the outside world. A managed platform does not make supply-chain risk vanish; it relocates it to a vendor whose job is to manage it, and whom you must judge on that basis. Brahmalabs’ relevant mechanisms here are digest-pinned sandbox images and vault-mediated credentials that keep raw secrets out of the agent process — this particular payload hunted crypto wallets, but a RAT delivered the same way into an agent process could just as easily have hunted the credentials that process holds.

When Mastra is the right choice

Advice you can act on, written as if you will check back in a year:

• You are a TypeScript-native team. If your product is Next.js or Node and your engineers live in one repo, Mastra gives you agents, workflows, memory, and evals in the same language and process as your product code, with server adapters for Express, Hono, Fastify, and Koa. Avoiding a separate Python agent service is worth a lot.
• You have an open-source mandate. Apache-2.0 means self-hosting, modification, and commercial use with zero licensing risk. Brahmalabs cannot match this at any price; there is no open-source edition.
• You need full code control. When the workflow logic gets weird — and production agent logic always gets weird — owning the code means you can eject from any abstraction. One caveat from the 1.0 launch discussion: users off the happy path reported friction and resorted to custom routes, which the co-founder acknowledged. But friction in code you own beats a wall in a platform you rent.
• You are embedding agents inside an existing product. If the agent is a feature of your software — your UI, your auth, your data model — a framework composes into it and a platform sits awkwardly outside it. This is Mastra’s home turf: Replit’s Agent 3 builds and runs Mastra agents inside Replit’s own product.
• You want deep agent-engineering primitives in TypeScript. Observational memory, LLM-as-judge scorers, and bidirectional MCP go deeper than what most platforms — Brahmalabs included — expose as tunable machinery.

When Brahmalabs is the wrong choice

• Self-hosting is a hard requirement. Brahmalabs is a managed platform; on-prem/VPC is an Enterprise engagement, not a download. Mastra self-hosts free under Apache-2.0, and its self-hosted Enterprise platform plan covers the governance add-ons.
• The agent is a feature of your product. Buy a framework, not a platform. See above.
• You need vendor maturity signals now. Brahmalabs has no public case studies, no customer logos, and SOC 2 Type II in progress rather than complete. Mastra names Replit and PayPal in production. If your procurement process weighs references, this comparison is currently lopsided.
• You want workflow-as-code in git. Brahmalabs has no CLI, git-sync, or Terraform provider yet; workflows are versioned in-platform. A Mastra workflow is a TypeScript file in your repo, reviewed like any other code.
• You need custom roles or SCIM provisioning. Brahmalabs offers three fixed roles; identity-heavy enterprises will hit that ceiling.
• You need deep RAG tooling. Brahmalabs’ knowledge base is file-based cited retrieval, not a full vector-RAG pipeline. Mastra’s semantic recall and memory processors — or a dedicated RAG stack — go further.

Where this leaves you

Score this comparison by who owns the operational remainder, not by feature count.

If you are a product engineering team shipping agents inside your own software, choose Mastra and do not look back. The primitives are real, the license is clean, the production users are named, and the things Brahmalabs would add — approval inboxes, sandboxes, audit — either belong in your own product surface anyway or do not apply.

If you are a platform, security, or operations team asked to make agents safe for people who do not read TypeScript — approvals for finance, audit for compliance, egress policy for security review — count the right-hand column of the inventory honestly. With Mastra you will build a reviewer UX, a credential vault, sandbox infrastructure, and an audit store, then operate all four while also patching the supply chain underneath them. Some teams should make that trade; it buys total control. Most teams making it have not priced the second year.

If you need both — agents embedded in product and governed automation for the business — the answer may genuinely be both tools, because they occupy different layers.

And if you are still unsure, the cheap experiment settles it: build one approval-gated workflow in each and show it to the person who will click approve. Brahmalabs’ free tier exists for exactly that test.