Best Practices - SabaothCloud

Sizing services

Start small and grow. CPU, memory and storage can be increased at any time from a service’s Settings tab. Storage can’t be reduced, so don’t over-allocate it up front.
Use presets as a starting point. Small suits development and light production traffic, Medium most production apps, and Large heavier workloads.
Use standbys for production. 1 primary + 2 standbys keeps your database available if the primary fails. Remember that each standby uses the same resources as the primary.
Keep development and production apart. Create separate services, or separate organizations, so a test can’t affect live data.

Leave automated backups on. They are on by default and cost nothing extra.
Take a backup before risky changes. Click Create Backup before migrations, bulk updates or upgrades.
Practise restoring. Restore a backup into a new service from time to time to check your data and your process. Restores never touch the original service.
Choose a plan with enough retention. If you need to go back further than 7 days, or need point-in-time recovery, use Professional or above.

Create a database user per application. Don’t share the owner account. Give each user the narrowest role it needs: Read-only for reporting, Read/Write for applications, Admin only for migrations.
Rotate passwords when someone leaves the team or a credential may have leaked. See Database users.
Keep services private unless you need public access. If you expose a service, add an IP allowlist straight away and avoid 0.0.0.0/0.
Always connect with SSL by adding sslmode=require to your connection string.
Turn on two-step sign-in for your account. See Account settings.
Give teammates the lowest role that works. Use Viewer for people who only need to look, and Developer for people who manage services.

One key per tool or pipeline, named after what uses it.
Grant only the scopes a key needs. Avoid Full Access unless it’s essential.
Set an expiry for keys used in temporary or experimental setups.
Store keys in a secrets manager or your CI provider’s secret store, never in source code.
Revoke unused keys. Check Last Used on the API Keys page regularly.

Use a connection pool in your application, and size it to stay well under the service’s maximum connections.
Turn on connection pooling for serverless functions or apps that open many short-lived connections. Use Transaction mode unless you need session features.
Set a connection limit on each database user so one application can’t use every connection.

Set a spending cap with an alert threshold on the Usage page.
Watch your quota on the Usage page before planned growth, and upgrade your plan ahead of time.
Delete services you no longer use. They stay restorable for 7 days.