mountable.io

Deno

Save a note with the TypeScript SDK in Deno, then read the same file in a fresh process.

mountable.io is a persistent filesystem for AI agents. A Deno script can save a Markdown note there so another process can open it after the first process exits.

mountable.io maintains this community example. It imports the released mountable-sdk package. It is not an official Deno integration, and it is not a Deno Deploy app.

Setup

Use Deno 2.9.8, an existing mountable.io account with a saved payment method, a filesystem and an API key that can access it. Storage and downloads are ordinary paid usage at the published prices. The example creates no account, filesystem or credits and makes no model calls.

Keep MOUNTABLE_API_KEY in your private environment or secret manager. Never put it in source, command arguments or logs.

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

The example pins Deno 2.9.8 and mountable-sdk 0.3.0.

Save a note and read it in a fresh process

deno task write --text "Deno note stays."
deno task read

write prints stored. The separate read prints:

Deno note stays.

Your backend selects the filesystem and the note path before starting the script. write accepts only --text. read takes no arguments. The script cannot take a filesystem id, a path or an API key from its arguments.

The tasks run with --no-prompt and only these permissions:

--allow-env=MOUNTABLE_API_KEY,MOUNTABLE_FILESYSTEM_ID,MOUNTABLE_NOTE_PATH --allow-net=mountable.io

There is no --allow-all. The script reads the API key before it opens a connection. If that variable is not permitted, Deno stops the process before any request. The refusal names MOUNTABLE_API_KEY and does not print the value. If mountable.io is not permitted, the SDK reports network_error and sends no request.

The first task run may download the pinned package through Deno's npm installer. The script's own requests still need the network permission above.

We ran write and read as two processes against production. The second process printed the same note through a read-only SDK handle.

Preserve the first note

The note must be nonempty UTF-8 text up to 16 KiB, at a path such as notes/deno-1710000000.md. Create-only writes send If-None-Match: *. A second write to the same path returns HTTP 412 precondition_failed and leaves the first note intact. A read-only handle's write returns HTTP 403 read_only.

Writes are not retried. After a timeout, read the note before writing again. A filesystem_spending_cap_reached error stops that user's billable filesystem work. See limits per end user. A filesystem cap does not limit a model provider's charges if you add a model later.

Cleanup

deno task cleanup --text "Deno note stays."

Cleanup reads the file, compares the bytes and deletes with the matching ETag. It refuses a different body. It does not remove the notes/ directory or delete a filesystem. Deleted data remains billable until reclamation.

To see the read-only refusal without replacing the note:

deno task readonly-write --text "Deno note stays."

That prints read_only.

Offline checks

deno task test

The tests use the released SDK against a loopback fake Files API. They cover a fresh process, a missing environment permission, a missing network permission, first-note preservation, read-only refusal and conditional cleanup. They make no cloud or model calls.

Sources: Deno permissions, Files API.