Mastra

Run Mastra tools in a workflow that saves a mountable.io note, then read the same file from a fresh process.

This community example uses real Mastra tools and deterministic workflows. One workflow writes a review note and reads it back. A separate process opens the same file. No model key or hosted Mastra service is required.

mountable.io maintains the example code. It stores a file through the TypeScript SDK. It is not an official Mastra integration or a backend for Mastra workflow snapshots, memory or checkpoints.

Prerequisites

Use Node 24+, an existing mountable.io account with a saved payment method, an existing filesystem and an API key with access to it. Normal usage prices apply. The example creates no account, filesystem, credits or model charges.

Set MOUNTABLE_API_KEY in your private environment or secret manager. Do not put it in command arguments or commit it. Your application authenticates the user and looks up their filesystem before constructing these tools. The CLI uses private environment variables for that trusted configuration.

git clone https://github.com/writeitai/mountable.git
cd mountable/examples/mastra-workspace
npm ci
export MOUNTABLE_FILESYSTEM_ID=your-filesystem-id
export MOUNTABLE_NOTE_PATH="notes/mastra-$(date +%s).md"

Dependencies are pinned to @mastra/core 1.79.0, mountable-sdk 0.3.0 and Zod 4.6.7. The lockfile fixes their dependency graph.

Save a note and read it in a fresh process

npm run handoff -- --text "Parser review complete."
npm run read

Both commands print Parser review complete.. The second command is a new process running a new read workflow. It opens the same file on mountable.io.

The tool definitions close over the backend-selected filesystem and path. createNote accepts only { text }; readNote accepts {}. Neither accepts a user id, filesystem id, path or credential from a caller. Unknown fields are refused. Never build those trusted settings from model output or an unauthenticated request body.

createStep(tool) wraps the actual Mastra tool definitions. The handoff runs create, maps its { stored: true } acknowledgement to {}, then runs read. The writer does not pass the note body to the reader. The read workflow starts with {} and retrieves the file through a read-only SDK handle.

Keep the first note

The tool writes with If-None-Match: *. Running handoff again with the same path fails with precondition_failed, preserving the original bytes. Workflow and step retries are disabled. After a timeout or connection failure, read the existing path before deciding whether another write is needed.

Paths are one Markdown file directly under notes/. Notes are nonempty UTF-8 text up to 16 KiB. Invalid text, missing files, denied permissions, quotas and rate limits stop the workflow. A 402 filesystem_spending_cap_reached stops that filesystem's billable work. Your backend can set a cap per end user. If you add model inference, its bill is separate from that cap.

The reader uses client.filesystem(id, "ro"). The service refuses writes through that handle. In a reader-only app, expose only the read tool and keep the reusable API key on the backend.

Cleanup

Use the exact original body:

npm run cleanup -- --text "Parser review complete."

The command checks the bytes and deletes with the matching ETag. If another worker changed the file, cleanup refuses the delete. It removes only this note, never notes/ recursively or the filesystem. SDK token sessions expire normally. Retained bytes can remain billable until reclaimed after logical deletion; see billing.

Offline checks

npm run typecheck
npm test

Tests execute real Mastra tools and workflows with the released SDK against a loopback fake Files API. They cover create-only preservation, scope refusal, read-only denial, failed writes without retries, byte bounds and cleanup.

Sources: Mastra tools, Mastra workflows, Files API.