Function Memory

Persistent memory for your Function without setting up a database.

Every newly published MiniUp Function receives env.MINIUP_MEMORY. Memory survives requests, new revisions, and republishing. Existing Functions receive the API when their runtime is refreshed or they are republished. No database credentials or raw SQL are exposed to Function code.

Save and read JSON

export default {
  async fetch(request, env) {
    if (request.method === "POST") {
      const settings = await request.json();
      await env.MINIUP_MEMORY.set("settings", settings);
      return Response.json({ saved: true });
    }
    const settings = await env.MINIUP_MEMORY.get("settings");
    return Response.json({ settings });
  }
};

Enable GET and POST for this example. Use API Key or Site Member access for private settings. Memory is shared by callers of the same Function, so your Function must enforce any caller-specific permissions before reading or writing data.

• get(key) returns the decoded JSON value, or null if missing. A stored JSON null also returns null.
• set(key, value) creates or replaces JSON data and resolves without a value. It follows JSON.stringify semantics: dates become strings, object properties containing undefined are omitted, and non-finite numbers become null. Top-level undefined, functions, symbols, BigInt, and circular values are rejected.
• delete(key) returns whether a key was removed.
• list() returns { keys, cursor }. Each entry contains key, size (JSON bytes), createdAt, and updatedAt (Unix milliseconds). It does not fetch values. The default page is 100 keys; choose 1–1,000 per page. Pass the returned cursor for the next page.

let cursor;
do {
  const page = await env.MINIUP_MEMORY.list({ cursor, limit: 100 });
  for (const entry of page.keys) console.log(entry.key, entry.size);
  cursor = page.cursor;
} while (cursor);
await env.MINIUP_MEMORY.delete("settings");

Isolation and limits

Each Function has its own keys. Other Functions and other owners cannot access them. The Test panel uses separate preview memory; public endpoints use production memory. Testing never reads or modifies production values. Both scopes count toward the same storage quotas.

Admins can change the first four limits using the existing default limits and per-user overrides. Production requests receive the current effective limits through their existing authorization check; no redeployment is needed. Preview gets current limits when you click Test (an issued preview expires after five minutes). Lower limits do not erase data. Reads and deletes still work; writes must fit the current limits. Updating an existing key does not consume an extra row. Sizes count UTF-8 JSON value bytes, including JSON punctuation, rather than JavaScript string length or database file size.

Quota checks and writes are atomic. Read–modify–write sequences across separate calls are not atomic; do not use them as reliable concurrent counters. V1 has no increment() or arbitrary SQL access. Catch errors when your Function needs a custom response; errors never include raw database details.

Deleting a Function removes its memory. Admins can inspect keys, view full JSON, delete a key, clear either scope, clear a Function, or clear all Function memory for a user. Destructive actions require confirmation. Failed lifecycle cleanup preserves a retryable Function record.

Related guides

• Create and publish a Function
• Function access
• Limits and plans