Running the platform
For whoever operates the server rather than uses the product.
Deployment
A deploy pulls the code, builds, migrates and restarts. It takes a backup first.
The deploy script updates itself
A change to the deploy script takes effect on the next deploy, not the one running it. Expect exactly one run of the old behaviour after you change it.
After a declaration change
Changing an entity declaration needs a registry refresh after the deploy. Without it the code runs and the type does not know about the change — a failure that looks like a caching problem and is not.
Backups
Taken before every deploy: the whole database, each customer schema separately so one can be restored alone, and the file store.
Retention differs by kind on purpose. Database dumps are small and change constantly, so many generations are kept. The file archive is large and changes slowly, so a few are enough — the rest was only disk.
A backup on the same machine is not a backup
Configure an off-site copy. Everything above protects you from a mistake, not from the machine.
Disk
Two things fill a disk quietly:
| Cause | Sign |
|---|---|
| Docker build cache | Tens of gigabytes accumulated over many deploys, nothing removing it |
| Backup retention | Many nearly identical copies of a large file archive |
The deploy reports disk use and warns above 85 %. Both causes have bitten this platform in production, and neither looked like the problem it was.
The reverse proxy
The proxy decides which requests reach the application and which are served by the front end.
A new root-level URL must be added to the proxy
Every time, in both variants. A URL the application serves but the proxy does not route returns the front end's not-found page — the symptom is a feature that works locally and is missing in production. This has already happened once, to the admin menu icons.
Two more traps worth knowing: a bind-mounted config file plus a git pull can leave the old file in place, so force-recreate rather than reload; and recreating a container pulls its dependencies with it, which can restart the application and take every site down for a couple of minutes.
Allowed hosts
A customer's own domain must be accepted by the application, or every route returns an empty not-found. When the proxy is the only way in, trusting it is the correct configuration; a hand-maintained list is a domain outage waiting for the next customer.