Audit Log
The logs view shows every relevant action in the system — who changed what and when:
- Configuration changes (portal credentials saved, settings changed)
- Customer/product merges and splits, automatically detected renames
- Mapping changes (Hetzner, Balena, weclapp)
- Snapshot deletions, maintenance resets
- Invoice runs and deleted PRE-invoices
- Sign-ins and user management
Filters by time range, type, portal, and actor make even long periods searchable.
Storage
The entries are additionally written to an S3-compatible backend (Hetzner Object Storage) — configured in Settings → Audit Log. This way the log is also backed up outside the database and can be stored in a tamper-proof manner.
Retention policy (Object Lock)
In the "Object Storage" dialog of the logs view, a retention policy can be enabled below the credentials. Multiverse then writes every log entry immutably (WORM, "write once read many"): for the configured duration, the object can neither be overwritten nor deleted — not even by Multiverse itself, and not even with the stored S3 keys. That is exactly what makes the log tamper-proof: whoever gains access can no longer cover their tracks in the log.
| Setting | Meaning |
|---|---|
| Compliance | The retention period cannot be lifted early by anyone — not even by the bucket owner. The strict variant for true tamper-proof retention. |
| Governance | Accounts with the special permission BypassGovernanceRetention can lift the lock. Well suited for trying out the mechanics first. |
| Retention period | 1 to 3650 days (10 years). The period applies per entry, from the moment it is written. |
- Prerequisite: The bucket must support Object Lock. This can be enabled only when creating a bucket (at Hetzner, the "Object Lock" option in the bucket dialog) and cannot be retrofitted later. As long as the configured bucket has no Object Lock, the toggle remains locked and the view explains why; Multiverse checks this directly on the bucket before saving the policy. To switch later, create a new bucket with Object Lock and configure it here.
- Nothing happens retroactively: The policy takes effect for newly written entries from the moment it is enabled. Existing objects stay as they are.
- Disabling is possible at any time — but entries already written remain locked until the end of their retention period. That is the whole point, and it cannot be undone (in compliance mode, not even manually).
- The connection test also reports whether Object Lock is active on the bucket; the active policy is shown as a chip next to the credentials.
Storage space
Locked objects cannot be deleted until their retention period ends — not accidentally, but also not for cleanup. With a long retention period, the bucket is therefore guaranteed to grow. Audit entries are tiny JSON objects, so in practice this hardly matters; still, the duration should be chosen deliberately (e.g. 365 days instead of "as long as possible").