One project per client, one bill for you
Projects are hard boundaries. Separate credentials, separate keys, separate audit trails, all under one account you administer.
- Isolation
- Per project
- Resources, keys and permissions never cross a project line.
- Handover
- Standard
- Postgres dumps and a Git repository, nothing bespoke.
- Audit
- Per action
- Who changed what is recorded, including automation.
A boundary you can explain to a client
Databases, applications, functions, storage and keys all belong to exactly one project. Cross-project access is not a toggle you can leave on by mistake.
Scoped keys per integration
Give the client's CI its own key with its own scopes. Revoking it does not break anything else you run for them.
Handover without a hostage situation
A client leaves with a PostgreSQL dump and their repository. There is no proprietary format holding their data.
Audit trail per project
Every mutation names its actor. When a client asks who deployed on Friday evening, the answer is in the log rather than in someone's memory.
Staging is just another project
The cheapest safety measure available: separate projects for staging and production, with separate credentials and separate blast radius.
One place to look
When a client calls about a slow page, the application logs, the database and the connection statistics are in the same dashboard.
Where the model stops
Projects isolate resources, but they share one server's capacity. A runaway workload in one project competes for connections and memory with the others. If a client needs a guaranteed capacity floor, that is a separate contract, not a checkbox.
Build the whole backend in one project
One plan, one dashboard, one command line interface. PostgreSQL, applications, functions, storage and realtime.