▣Instances

A complete customer system of its own: its own environment, its own database, its own containers, its own address and its own licence.

Two instances cannot see each other, even if they run on the same server. That is the difference from a shared database with tenant identifiers: here there is no way of accidentally reaching across the boundary.

In the customer file with “+ Create an instance”. In one go, this produces a complete customer system: environment, database, containers and licence.

The order is fixed: issue a licence first, then the instance can be created — it starts with the key. Everything else (modules, budgets, revocation) is then handled by the daily sync.

For products for which nothing has been set up yet, the provisioning service creates nothing; such instances are set up by hand.

From the customer file, you start, stop, back up and update — the output is shown live as it runs, so you can see where it is stuck if something gets stuck.

Update first backs up the database, then fetches the current version, rebuilds and runs the migrations. This takes a few minutes; the instance is briefly unavailable during this time.

Stop makes the instance unreachable for the customer. The data stays untouched.

The switch enables routing for the domain — but it only makes sense once the DNS record is in place. Before that, issuing the certificate fails, and does so several times, because it keeps trying again.

So the order is: set DNS first, wait until it is known, then enable. The other way round, you end up blocked by the certificate authority and have to wait an hour.

First, a backup is made: database, environment files and all uploaded files. After that, images, database and files are removed; the subdomain and storage space become free again.

This is distinct from removing the entry: that only deletes the row in the administration. Containers, database and files on the server remain — taking down deliberately stays manual work, so that nobody accidentally removes a running customer system.

With “Check the instance” in the customer file. The run answers the same questions as the system status inside the instance — only from outside, and without anyone having to sign in there.

This is also the way to close the blind spot mentioned at the start: a status page inside an instance cannot report that instance’s total failure.

1. Create the customer — the company is enough, together with the monthly price.
2. Issue the licence — the instance starts with the key; without a licence you cannot go any further.
3. Brand and logo, if wanted.
4. Create the instance — environment, database, containers and licence in one go.
5. Set DNS, wait, then enable the domain.
6. Invitation to the customer.

Doing step 5 in the wrong order is the most common mistake and costs an hour of waiting.

Read it — it is the only place where you can see where things are stuck when they are stuck.

Two things are worth knowing: a run that stops moving has usually hit a step that is waiting for something (a certificate, a migration). And a run that ends with an error message has usually already created part of it — check what exists before a second attempt.

While an action is running, the buttons are locked. That is intentional.

Not during the customer’s main working hours: the instance is briefly unavailable during the update.

The procedure is safeguarded — first the database is backed up, then the current version is fetched, rebuilt and the migrations are run. Even so: announce it if the customer is working with it, and do not update on a Friday afternoon.

• Take down backs up first and then removes images, database and files; the subdomain and storage space become free.
• Removing the entry deletes only the row in the administration. Containers, database and files on the server remain.

This is deliberately separate: taking down stays manual work, so that nobody accidentally removes a running customer system. Anyone who is only tidying up the administration should not delete anything.

In this order: attachments from connected mailboxes, uploaded files (candidate documents, PDFs, images) and the database itself — the latter usually matters least.

If an instance grows noticeably, the tick for stored mail attachments is almost always set. That is a mailbox setting, not an operational problem.