Mastra won the TypeScript agent framework race — 26,000 GitHub stars, 300,000 weekly downloads, and comparison posts that end the same way: if your team writes TypeScript, use Mastra. The quickstart is genuinely five minutes. Then you try to keep it running: the dev server wants ~2 GB of RAM, the production build needs a supervisor and safe redeploys, Studio ships with no login screen, and the databases holding your agent's memory need a disk that doesn't vanish. Mastra's own changelogs say it plainly — the rough edges "show up once you start running real workloads." Here's how to run it for real: the production server, always on, on its own Firecracker microVM.
What Mastra is
Mastra is the open-source TypeScript framework for AI agents. An agent is a file in your repo — a model, instructions, tools, memory — not a configuration in someone's cloud. Around it: tools (typed functions the model can call), workflows (typed steps chained into pipelines), and memory backed by a real database. On top: Studio, a web UI where you chat with your agents and watch every tool call.
It's Apache-2.0, built by the team behind Gatsby, and v1.0 since January 2026. Switchers are blunt about why: one developer who moved a production agent off LangGraph TS rebuilt it in Mastra in 18 hours instead of 41 — and cut P95 latency in half. mastra build compiles the whole project into a standalone Node.js server that exposes each agent as a REST endpoint and serves Studio — that server is what production means here, and it's what jurniti runs.
Why a real microVM for Mastra
Mastra's docs offer serverless deployers and their own hosted platform. Both are fine answers to "where do I put a function." A microVM is the answer to a different question: where does my agent live?
An agent isn't stateless. Its memory database grows with every conversation. Its project source is something you keep editing. Its .env holds your model keys. On serverless, that state scatters across managed services; on jurniti it's all one place — your project directory, on a persistent volume, on a machine that's yours.
Isolation is hardware, not a namespace. Your Mastra server executes arbitrary TypeScript with your API keys in its environment — and this June's npm supply-chain attack on the Mastra org showed exactly what's at stake. jurniti gives every tenant a dedicated Firecracker microVM: own kernel, KVM boundary, one tenant per box. Our installs are version-pinned and run script-less (--ignore-scripts), and every image is boot-tested before it ships.
Studio gets a real home. Open-source Studio has no auth — you should never expose port 4111 raw. On jurniti, Studio is served through your authenticated portal at your own TLS subdomain, and the edit loop lives in the browser: open the terminal or file browser, change your agent, run mastra-rebuild. It builds atomically and rolls back to the last good build if yours fails — your Studio never goes dark from a typo.
BYOK is architectural. Your key goes in your project's .env, inside the VM. One OpenRouter key covers hundreds of models; switching providers is a one-line env change. jurniti never sees a key and never marks up a token. And it's reversible: 30-day money-back guarantee, workspace kept 7 days after cancellation.
Run Mastra in 3 steps
By hand this is a VPS, Node 22, a pinned scaffold, mastra build --studio, a systemd unit, a reverse proxy with TLS and auth, and patching forever. jurniti runs the box; you write the agents.
1. Pick a plan and pay
Pro is the natural starting point — it serves Studio at your own subdomain. Check out, and provisioning runs automatically the moment payment confirms.
2. Your microVM boots with a Mastra project serving
A fresh microVM boots with a complete, pre-built Mastra starter project — example agent, tool, and workflow included — already serving Studio. Add your model key to .env from the quickstart, and you're chatting with your first agent in minutes.
3. Make it yours
Edit src/mastra/ in the terminal or file browser, run mastra-rebuild, and watch your own agents and workflows appear in Studio. Every agent is also a REST endpoint your apps and cron jobs can call. Total time from checkout to your first agent reply: about three minutes.
What people run Mastra for
- Agents as endpoints.
POST /api/agents/yourAgent/streamfrom a webhook, a cron job, or your product — the agent answers 24/7. - Typed workflows against real APIs. Deterministic steps where you need reliability, model calls where you need judgment.
- Agent memory that compounds. Conversations and preferences accumulate in a database on your persistent volume — yours to query, back up, or export.
- A living project, not a deploy artifact. Edit the source on the VM, rebuild in place, keep the whole thing in git.
Snapshot a configured Mastra project into a template and fork it — your agents and source travel, your keys and memory never do.
jurniti vs a laptop vs a DIY VPS
| jurniti | Your laptop | DIY VPS | |
|---|---|---|---|
| Always on | Yes | No — it sleeps | Yes |
| Serves | Production build (mastra build --studio) | Usually mastra dev (~2 GB RAM) | You wire it up |
| Studio auth + TLS | Portal auth at your subdomain | Localhost only | You configure both |
| Failed rebuild | Rolls back, keeps serving | Dev server crashes | Your problem at 2am |
| Supply-chain posture | Pinned, script-less installs | Whatever npm pulled | You audit it |
| Model keys | Yours, never leave the VM | Yours | Yours |
| Refund | 30-day money-back | n/a | None |
Pricing
Because Mastra ships Studio as a web dashboard, Pro ($49/mo, $490/year) is the natural starting point — that's the plan that auto-serves Studio at your own TLS subdomain. Starter ($25/mo) runs the production server comfortably too (it idles around 350 MB), and the rebuild helper is built to work within Starter's memory. Every plan includes the 30-day money-back guarantee, and your model spend is separate and never marked up.
Prefer an agent that manages other agents, or a chat-first assistant? See the guides for Paperclip, Hermes, and OpenClaw, or compare plans on the pricing page.