perishable

Overview

perishable addresses a problem that has no clean solution and several bad ones: a browser application wants to call an LLM API, and the key cannot be in the browser. Shipping the key in client-side JavaScript exposes it to anyone who opens developer tools. Not shipping it means building a backend, which for a static site or a demo is a disproportionate amount of infrastructure.

The design is a self-hosted Node proxy plus a browser SDK. The client obtains a short-lived JWT session rather than a key, scoped and time-limited, and calls the proxy; the proxy holds the upstream credential and forwards to any OpenAI-compatible provider — OpenAI, Anthropic, OpenRouter, or a local Ollama instance. Sessions are bound to a browser fingerprint, entropy is collected to make trivial automation more expensive, and rate limits are applied per fingerprint rather than globally so one abusive client cannot exhaust the budget for everyone.

The scope statement is unusually blunt and deliberately so: this raises the cost of casual abuse and is not bot-proof. A determined attacker with a headless browser and patience will obtain sessions. What perishable prevents is the realistic failure — a key scraped from a public bundle and used at scale within hours — and presenting it as anything stronger would invite exactly the misplaced confidence that makes security tooling dangerous.

Several things it also is not: a hosted service, an observability layer, and a per-user authentication system. If you know who your users are, authenticate them properly and issue credentials against identity; fingerprinting is what you reach for when you cannot, such as on a public demo or a documentation site with a live playground.

The licence is pending. The source is public and the repository is readable, and until a licence file is present we do not describe the project as open source, because the distinction is legally meaningful and eliding it would be misleading to anyone evaluating it for use.

Where it loses: Cloudflare's API gateway and HashiCorp Vault are mature, well-supported and solve the general credential problem properly. Both assume the code calling the API runs somewhere you control; neither is designed for a browser that must call an LLM provider directly, and that narrow case is the only thing perishable offers over them.

Within the portfolio, perishable and anouk answer two halves of the same client-side question. anouk assumes the user brings their own key and needs a framework around it; perishable assumes the operator's key must be used and must not be exposed. A project that can choose the first arrangement should, because it removes the threat entirely rather than raising its cost. perishable is for the cases where the product shape forbids asking a visitor for a credential before they can try anything.