Alchemist: Runtime, Data, and Regions
What your Alchemist app runs on, the runtime rules it runs under, where its data lives, how that data is backed up, and how AI calls through the platform handle your data.
This page collects the facts teams usually ask about before they commit to hosting an app on Alchemist: the runtime, where data lives, what is backed up, and how AI calls handle your data.
The runtime
Every Alchemist app runs as a Deno program (TypeScript) in a container the platform builds and manages. The same rules apply to every project:
- Fixed entry point. The platform starts your app’s
main.tsitself. You cannot change the container command or bring your own image. - Non-root, read-only filesystem. The app runs as an unprivileged user on a read-only filesystem, with no write access by default. Store files in your project’s storage bucket (see below), not on local disk.
- Network, environment, and file reads are allowed; native libraries (FFI) are not.
- No subprocesses by default. An app cannot start other programs unless Chipp grants a specific, reviewed command (for example a document renderer). Python, Node, shells, and other language interpreters are never allowed, even as a subprocess.
If you are bringing existing code in another language, plan to port the parts that run in production to TypeScript. Tools that only run during development, such as data-preparation or analysis scripts, can stay in their original language outside the app.
For CPU and memory per resource class, replicas, background workers, and the 10-minute request time limit, see Deploys and Domains.
Where your app and data live
| Component | Service | Location |
|---|---|---|
| App and worker pods | Google Kubernetes Engine | Google Cloud us-central1 (Iowa, USA) |
| Database | Google Cloud SQL for PostgreSQL | Google Cloud us-central1 |
| Uploaded files | Cloudflare R2 (S3-compatible) | Cloudflare |
| Cache | Redis, run by the platform | Google Cloud us-central1 |
All projects run in a single region today. There is no regional choice (for example a Canadian or EU region) yet. If you need one, contact support@chipp.ai.
The database and file storage are encrypted at rest with keys managed by Google and Cloudflare respectively.
Backups and restores
| Data | What is backed up | How to restore |
|---|---|---|
| Database | Automated daily backups plus point-in-time recovery, kept for about 7 days | Contact support@chipp.ai. Restores are carried out by Chipp, not self-serve. |
| Uploaded files | Not backed up or versioned. A deleted or overwritten file cannot be recovered by the platform. | Keep your own copies of anything you can’t lose. |
| Cache (Redis) | Not persisted. Contents can be lost on any restart. | Use it only for data you can rebuild. |
| Code | Every change is a commit in your project’s Git repository, with full history. | Roll back a release, or revert in Git. |
Rolling back a release does not restore data. A rollback puts earlier code back live; it does not undo database changes or bring back deleted files. If your app holds data you can’t afford to lose, add a scheduled export of your database and files to storage you control, and test restoring from it.
AI calls and your data
Your app reaches AI models through the platform’s built-in AI connection. Its credentials are injected into every deploy, so you don’t manage provider keys.
- Anthropic Claude models run on Chipp’s Anthropic account with zero data retention: prompts and outputs are not stored by Anthropic after the response, and are not used for training. The exception is the Fable family, which runs on a separate account where Anthropic’s standard retention applies.
- Other providers (OpenAI, xAI, Google, Cerebras, and models via OpenRouter) are available too and run under each provider’s standard API terms.
For confidential or regulated material, use Claude models other than Fable.