Platform
Ten screens covering the environment, integrations, deployments, storage, flags, limits, jobs, webhooks and API keys.
Platform is the group for the machinery: what the installation is connected to, what it is allowed to spend, and what other software is allowed to call. Most of it is set once, and two of the screens are worth reading properly before you touch them.
Environment
Platform → Environment is the live view of the nineteen names: each one with its home, what it is for, and
whether it is Set, Missing or Not set. It never shows a value, only a four-character hint such as
re_...f3a9.
Names the panel is allowed to write, because the app reads them at request time, can be set from this screen. The rest show the exact command to run instead, because a deployment's environment is set on the deployment. Any name that has a sensible default of its own is counted separately, so an unset optional name never reads as a fault.
Integrations
Platform → Integrations is what the installation can offer at all: Git providers, deployment targets,
databases, MCP servers and OAuth applications.
| Kind | What it enables |
|---|---|
| OAuth | GitHub and similar, for pushing code to a repository somebody owns |
| MCP | Model Context Protocol servers, which bring their own tools |
| Deployment targets | Where a project can be published, such as a hosting provider |
| Databases | Managed Postgres and similar, for projects that need one |
A card is disabled with the reason when its application is not registered, which is how the panel avoids offering a control that would fail.
Deployments
Platform → Deployments is every deployment the installation has performed: the project, the target, the
address it was published at, and the ability to roll one back. The limits on this screen decide how many
deployments a plan may keep and how long their history is retained.
Databases
Platform → Databases holds the provider keys for the managed databases a project can be given, their quotas,
and their backups. A project's database is created through the provider rather than inside this installation, so
this screen is about credentials and ceilings rather than about tables.
Storage & files
Platform → Storage & files reports what is being stored, by kind, against the limits, with the retention rules
that decide how long a deleted item stays in the bin before it is purged.
| Number | What it means |
|---|---|
| Bytes by kind | Pictures, documents, and anything else an account has uploaded |
| Limits | What a plan allows, and what the installation allows in total |
| Retention | How long the bin keeps something before purging it |
Feature flags
Platform → Feature flags is how a feature is turned on for some people before everybody.
| Mode | What it means |
|---|---|
| Off | Nobody has it |
| On | Everybody has it |
| Rollout | A percentage of accounts, by a stable hash of the account, so it does not flicker |
A flag can also be limited to particular plans or named addresses, which is what a beta usually wants. Flags are resolved where the decision is made rather than in the browser, so a flag cannot be turned on by somebody editing a request, and the app is told only the names of the features that are on.
A flag is not a setting
A setting is something the owner chooses for the installation. A flag is a temporary switch for trying something. Leaving flags on forever is how a product ends up with two behaviours and no way to know which one somebody has.
Rate limits & abuse
Platform → Rate limits & abuse is the ceiling per plan and the list of addresses that are not being served.
- Per plan: turns per minute and per hour. The shipped fallback for a plan with nothing set is ten per minute and a hundred and twenty per hour.
- Blocked addresses: an address with a reason, which is required. Blocking takes effect on the next turn and deletes nothing.
Blocking is not deleting
A blocked address cannot use the product, and everything belonging to it is
still there. If the intent is to remove somebody rather than to stop them,
that is People → Users, and that is the screen with the typed confirmation
on it.
Jobs & queue
Platform → Jobs & queue is the scheduled work: what runs, when it last ran, what failed, and a button to run one
now. The scheduled functions live on the deployment, so this screen is a window onto them rather than a scheduler
you have to keep alive. A failure here is usually a missing key or a rate limit at somebody else's service.
Webhooks
Platform → Webhooks is how this installation tells other software that something happened.
Add an endpoint: the address to call, and which events should call it.
Rotate the signing secret when it needs to be replaced. It is copied to your clipboard, and the old one stops working immediately.
Test sends a sample payload to that address so you can see the other side receive it.
Retry a delivery, or clear the log, when you are done debugging.
API & keys
Platform → API & keys is programmatic access to the installation.
| Field | What it decides |
|---|---|
| Name | What the key is for, so that a year from now it means something |
| Scopes | What the key may do, from reading models to reading an account's own data |
| Ceiling | How much the key may spend |
| Expiry | When it stops working, which is the field most people leave empty by mistake |
The secret is shown once, at creation, and never again. It can be extended, and it can be revoked, and there is a single button that revokes every key at once for the case where one has leaked.