Next steps
What to set up once your first service connects — an application role, a verified backup, a second factor, your team, and a plan for importing data.
Your service is running and you can reach it. Five things are worth doing before you put real traffic on it.
Each one is a short task here and has a page of its own with the detail.
1. Create a role for your application
Do not run your application as the managed elevated role. Create a role scoped to the database and schema it needs, and grant it only what it uses.
CREATE ROLE app_user LOGIN PASSWORD 'REDACTED-EXAMPLE-ONLY';
GRANT CONNECT ON DATABASE appdb TO app_user;Roles are created in SQL, because the managed elevated role holds CREATEROLE. One role per
component that connects means a leaked application credential cannot drop a table.
See databases and roles and privileges. The step people forget is default privileges, and the symptom arrives one migration later.
2. Confirm your backup is verified
- Open the service and select the Backups tab.
- Read Last verified restore.
Your first restore verification is due within 48 hours of your first successful backup. Until one has completed, the field reads Not measured yet.
Last backup and Last verified restore are different facts. The first says a backup job finished. The second says the backup restores, which is the one worth having. See restore verification.
3. Turn on two-factor authentication
If you skipped it during signup, open Security and enrol. You need an authenticator application; a six-digit code from one is the only second factor Balta supports.
An owner or an administrator can also require it for everyone, under Security → Organisation policy → Require two-factor authentication. There is no grace period when they do.
See multi-factor authentication.
4. Invite your team with the narrowest role
Invitations are sent from Team. There are five roles:
| Role | What it can do |
|---|---|
| Owner | Full control, including billing, deletion and transferring ownership |
| Administrator | Everything operational. Cannot change the payment method or delete the organisation |
| Developer | Creates and manages services in the projects they belong to, including credentials and restores |
| Billing | Invoices, payment method, subscription and VAT details. No access to services, credentials or data |
| Viewer | Read-only: service health, backups, the audit log and your data. Never sees credentials, never changes anything |
An invitation lasts seven days, works once, and works only for the address it was sent to.
No actor may grant a role it does not itself hold, and that is checked again when the invitation is accepted rather than only when it is sent.
5. Plan your import before you start copying
Moving an existing database means pg_dump and pg_restore. Read the
compatibility notes first. They cover what will not come
across: anything in the dump that needs superuser, any extension outside the supported catalogue, and
an encoding or collation that differs from the target.
Finding one of those after six hours of copying is a much worse day than finding it before you start.
The commands are written out in full on dump and restore.
What you will see
Once all five are done: an application role that is not the elevated one, a Last verified restore time on the Backups tab rather than Not measured yet, a second factor on your account, your colleagues on the Team screen, and a migration plan you have read rather than discovered.
Also worth knowing
Each service has a weekly maintenance window, shown on its Configuration tab in UTC. Anything with expected impact is announced at least 72 hours ahead. See maintenance windows.
Six backup and archive conditions email you. That is the whole set, and alerts lists them.