/stash-managed-platforms

name: stash-managed-platforms
description: >-
  Implement CipherStash encryption on a managed AI app platform — Lovable, v0,
  Bolt, Replit, and anything else with no developer-controlled shell, an
  edge/Workers runtime, a database role that is not `postgres`, and schema
  changes only through the platform's own migration tool. Covers the one fact
  that decides whether the product works there at all (use `@cipherstash/stack`
  with the `wasm-inline` entry — `@cipherstash/protect` is the deprecated
  predecessor and its native module will not load), running `stash auth login
  --json` headlessly in an ephemeral sandbox, minting deployment credentials
  with `stash env`, installing EQL as a role that is not `postgres`, which query
  predicates survive PostgREST, and how to construct `encryptedSupabase` inside
  a Worker by declaring your schemas. Also covers the platform guards that break
  installs: command-time ceilings that kill the EQL bundle partway
  (half-installed schema after a 600s limit), the PostgREST grants the installer
  never emits, minimum-release-age cooldowns refusing a fresh release ("version
  too new"), and secrets handoff when there is no secrets API. Use when the
  project is hosted on one of these platforms, when there is no terminal you
  control, when a native module fails to load in the deployed runtime, when an
  EQL install times out or PostgREST calls fail with permission errors, when a
  freshly published package refuses to install, or when you are about to
  conclude CipherStash cannot be used here.

CipherStash on Managed AI App Platforms

Read this first: it does work here

If you are on Lovable, v0, Bolt, Replit, or a similar hosted builder, and you have found `@cipherstash/protect` and inferred from its `@cipherstash/protect-ffi` dependency that CipherStash needs a native Rust addon and therefore cannot run on an edge runtime — **that inference is about the wrong package.**

• **`@cipherstash/stack` is the current package.** Import the `@cipherstash/stack/wasm-inline` entry. It carries the WASM build of the same engine as a base64 blob inside the JS: no native binding, no separate `.wasm` fetch, nothing for a bundler to externalise, no `--allow-ffi`.
• **`@cipherstash/protect` is the deprecated predecessor.** Its native FFI will not load in a Worker or an Edge Function. Do not install it, and do not use it to decide what the product can do.

An agent working on one of these platforms previously spent a full turn concluding CipherStash was impossible in a Lovable project before finding `stash` and the WASM entry. Nothing about that conclusion was true. Everything below is the rest of what that turn had to discover.

The `stash-edge` skill is the full guide to the WASM entry (per-runtime import specifiers, the client surface, how one schema module is shared across both entries). This page covers what is specific to *managed* platforms.

When to Use This Skill

Use it when the environment has any of these four properties — they travel together and each one changes the setup:

1. **No shell the developer controls.** Commands run in an ephemeral sandbox, or not at all. 2. **An edge / Workers runtime** for server code. 3. **A database role that is not `postgres`** and is not a member of it (Lovable's is `sandbox_exec`). 4. **Database changes only through the platform's migration tool**, not a psql session.

Do not use it for a normal Node deployment on a VM or a container — that is `stash-deployment`.

The CLI authenticates headlessly. Use it.

The most common wrong turn after the WASM one is assuming the CLI cannot log in without a browser on the machine, and reaching for a raw EQL `.sql` release asset instead. The device flow is designed for exactly this case.

stash auth login --json --region us-east-1

`--json` emits newline-delimited JSON on stdout, one object per line, and deliberately does **not** open a browser — the human opens the URL, not the agent's host. The first event, `authorization_required`, carries `verificationUri` / `verificationUriComplete` and a `userCode`; print it and ask the person to approve it. Credentials are written to `~/.cipherstash`, which exists fine inside a sandbox.

Three things to get right:

• **`--region` is required in a non-TTY.** Without it (or `STASH_REGION`) the region picker cannot render and the command exits `region_required`. `stash auth regions --json` lists the valid slugs.
• **After printing `authorization_required` the command blocks**, polling until approval or expiry (~900 s). Run it as a background task with a generous timeout — do not treat the pause as a hang.
• **Authenticate before `stash init`.** An unauthenticated `init` tries to start a login of its own.

Then drive everything else through the CLI: `stash manifest --json` is the authoritative command surface, and `--json` modes exist on the commands an agent needs. Never `cat` anything under `~/.cipherstash` — the CLI reads it for you, and its contents are secrets.

Deployment credentials: `stash env`

The four `CS_*` variables a deployed app needs are minted in one command:

stash env --name my-app-prod --write .env.production.local

`--name` is **required** in a non-interactive run. Without `--write` the dotenv block goes to stdout and progress UI goes to stderr, so redirecting into a file or piping into a secret store is safe. With `--write` the file is mode 0600, and an existing file is *refused* non-interactively rather than silently overwritten. The access key is shown exactly once.

Put those four values into the platform's backend-secrets UI. That is the whole story on these platforms and it works as-is — `stash-auth` is canonical for what each variable is and how the strategies use them.

The database role is not `postgres`, and that is fine

`stash eql install` completes as a non-`postgres` role. Only three owner-scoped `ALTER DEFAULT PRIVILEGES FOR ROLE postgres` statements are skipped,