Production security practices

Keep database credentials and developer tokens in server-side secret stores. A frontend application should call your application server, which enforces application authorization and accesses the database. Do not embed database URLs in browser bundles or mobile apps.

Use separate credentials and workspaces for development and production. Create an application user with the needed permissions and a distinct credential for migrations. Do not use the connection panel’s privileged account as a convenient default for every workload.

Validate controls at the layer where they matter: test engine permissions after a change, inspect allowlist_enforced, and verify TLS from the application runtime. A label or saved setting is not evidence of enforcement.

Rotate credentials deliberately: update the secret store, reconnect the application, verify its intended operations, and retire old credentials. For PostgreSQL permission reduction, use a replacement credential and deletion of the old one until grant updates are supported.

Restrict workspace membership to trusted collaborators because manual backup deletion/restore is available to members. Issue expiring developer tokens with the smallest required scopes. Read scopes exclude credential retrieval and raw commands; api still excludes account, billing and token-management operations.

Parameterize application queries, redact connection strings and tokens from logs, and avoid sensitive literals in editor queries. Management audit logs do not replace application authorization logs or a verified data-access audit.

Test restore on a disposable target of the same engine before relying on backups. Verify MongoDB indexes and Redis key types/expiry times as well as application data. See known limitations for the current boundaries that affect these decisions.