Scoped credentials for machines
Project-bound API keys with explicit scopes and optional IP rules, so automation gets exactly the access it needs.
- Bound to one project
- Scope per capability
- Optional IP restrictions
One project, one key
A key cannot reach across projects. Compromising a key in a staging project does not expose production data.
Scopes, spelled out
db.query.read, db.query.write, blob.read, blob.write, app.read, function.read and the rest. Grant the ones the integration uses and nothing else.
Separate keys per integration
One key per consumer means you can revoke one without breaking the others, and the audit log tells you which system did what.
IP rules when they help
Restrict a key to known egress addresses where your infrastructure has them. It is defence in depth, not a substitute for scoping.
Server-side only
An API key in a browser bundle is a published secret. Browser clients get short-lived tickets instead.
Automation tokens for CI
The CLI can issue a non-expiring automation token for pipelines, kept in your CI secret store rather than a build argument.
Billing state gates writes, not reads
An inactive managed subscription blocks platform mutations, including through the CLI and API keys. Sign-in and read access stay available so you can fix the billing problem.
Build the whole backend in one project
One plan, one dashboard, one command line interface. PostgreSQL, applications, functions, storage and realtime.