Docs / security-privacy

Your code, data & security

Your project's code lives in a git repository you can export at any time, the secrets you give it are encrypted, and every project builds in an environment of its own. Here are the mechanisms that exist, and nothing beyond them.

Your code is yours

Every project gets its own git repository, and the AI commits to it after each run. That is why you can walk away with the result: push it to your own GitHub account, or download a ZIP, whenever you like, and what comes out is a working application you run yourself. See export your source code.

Deleting a project is the other side of that, and it is permanent and immediate: the database, the repository, every deployment, uploaded files and run records all go. Export first if you want to keep anything — see creating & managing projects.

How a project is isolated

Each project's AI work happens in its own build environment, with only that project's files mounted into it. One project cannot read another's code.

It runs as an unprivileged user with elevated permissions dropped, a read-only system filesystem, and caps on memory and running processes; it shuts down after about 10 minutes idle, and lives at most 4 hours.

A project with a database gets a real one of its own, with its own name, user and password.

Secrets you give us

Values set in the Env variables editor are encrypted before storage and never sent back to your browser: saved values render as dots, and editing one replaces it rather than revealing it. The same encryption covers your database connection string, the tokens for accounts you connect such as GitHub, and the payment identifier below.

Your .env file never enters the repository at all — every project is scaffolded with it ignored by git, so real values are not there to leak, which is why an export cannot carry them out.

Two things deserve a plainer warning:

  • API keys for your project's REST API are stored hashed. The full key is shown once, at creation, and cannot be recovered — lose it and create a new one. See REST API for your data.
  • EXPO_PUBLIC_ variables are not secrets. They are written into the JavaScript bundle your phone downloads, so anyone holding the app can read them. Never put a server key in one.
  • NEXT_PUBLIC_ variables are not secrets either, for the same reason on the web side. This matters most for the AI token: it spends your credits, so a copy in the browser is a copy anyone can spend. After a run the platform checks for this and stops the run if it finds it.

Sign-in sessions are stored hashed too — the value in your browser cookie is not in our database in readable form.

Publishing to Showcase is scanned first

Listing a project snapshots it, and that snapshot is checked before anything is created.

Files that hold credentials never make it in: every .env, keystores and private keys, service configuration files, build output. Everything that survives is read line by line for hardcoded credentials — API keys, access tokens, connection strings, private key blocks. A single one blocks the publish, and the dialog names the file and line so you can move the value into .env and try again. Nothing is created until the scan passes.

A listing is public code by design: buyers receive your code and your schema, never your data. Selling on Showcase has the details.

Payments

Subscriptions and template purchases are processed by Midtrans. Card numbers and e-wallet authorisations are entered on Midtrans's own checkout and never reach our servers. For auto-renewal we keep an identifier issued by Midtrans — not your card — encrypted like any other secret.

What we keep

  • Run records. For each AI run: what was sent to the model, what came back, timing and token counts. Values matching a known credential format are masked before the record is stored. Deleted automatically after 30 days.
  • Activity records — which action, when, by whom — for 90 days.
  • Uploaded files attached to prompts, for 30 days.

When you report a failure, our team can open your project to investigate it. That means the run records above, and — on a deployment where the operator has turned it on — your project's files, its knowledge file, and rows from its database. Two exclusions are enforced in code rather than promised: files that hold credentials (every .env, keystores, service configuration) are refused outright, and column values whose names look like a secret — password, token, hash, apikey, credential — are replaced before the row leaves the server, with the column name still visible so the shape of your data reads. Nothing can be written or run this way; there is no query console on that path. Every one of these reads is recorded — who read what, and when. Deleting a project deletes its records with it.

Reporting a problem

Use the Send feedback button, category Bug, and include the time and the project name. Do not paste keys, passwords or connection strings into it — describe where the problem is instead.

Account deletion is not self-service yet; request it the same way. The privacy policy covers what is collected.

Limits & notes

  • A running mobile preview is reachable by anyone with the link — a development server on a public address, with no login. Stop it when you are done; see preview on your phone.
  • Exporting to a public GitHub repository publishes whatever is in the code, including anything the AI wrote straight into a file. Keep it private and read it first.
  • A public Showcase listing exposes your code on purpose — the scan stops secrets, not sharing.
  • Preview and production share one database by default, so test rows are live rows — see your project database.
  • We hold no security certification and have had no third-party audit. This page describes mechanisms, not an assurance beyond them.
  • Behaviour may change during alpha.

Related