Installation & Updates

Installation is mostly straightforward. What matters is the handful of decisions taken then that are awkward to revisit.

Where to find it

Architect Panel → Configuration:

• Site Settings — the settings fixed at installation
• Multitenancy — the tenancy model

Architect Panel → Integration & Connections:

• Database Hosts — where data lives
• Deployments — how versions are applied

Decide these before you start

1. Your domain. It becomes your identity to every connected application, every passkey and every OpenID client. Changing it later invalidates all of them.
2. The tenancy model. Shared or separate databases — a migration afterwards, not a setting.
3. Where the data lives. Jurisdiction, and who has access to the infrastructure.
4. How updates will be applied, and by whom.

Everything else can be adjusted. These four cannot, comfortably.

Have more than one environment

At minimum something that is not production. Without it, every update and every configuration change is tested on live data, and eventually one of them will be tested by your users.

It need not be large — it needs to exist.

Non-production data needs care

A copy of production is a copy of your personal data, with the same obligations and usually weaker controls. Either restrict it as tightly as production, or use generated sample data instead.

And make sure it cannot send. A test environment with live mail credentials will e-mail real customers, and it is a mistake made regularly.

Record the installation

Version, when it was installed, what was configured, where the data is, who has access. This is the information needed urgently and rarely, usually by somebody who was not there.

Keep it current

A regular cadence rather than updating when forced. An installation left for two years is a large, risky project to bring forward; one updated quarterly is a routine afternoon.

Confirm backups by restoring

Not by checking that a backup job reports success. A backup nobody has restored is a hypothesis, and the moment you need it is the worst time to discover it was incomplete.

Restore one into a non-production environment, at least annually.

Know who to ask

Before something goes wrong. Support arrangements, escalation, and who holds the credentials — all obvious until the person who knew them is unavailable.

Worked example

An organisation settles its domain, tenancy model and hosting jurisdiction before installing, keeps a staging environment refreshed from production with mail sending disabled at the account level, and restores a backup into it annually — which once found a backup that had been silently excluding one table for months.

Recommendations

• Settle domain and tenancy before installing.
• Have a non-production environment, and stop it sending mail.
• Restore a backup annually rather than trusting the job.
• Write the installation down.