Retention
Every kind of record Velrix keeps has a retention period: how long it is kept before it is deleted. Each period is a policy of the part of Velrix that holds the data, and all of them are on one tab: Policies › Retention.
The periods
| Policy | What is kept | Default | Set for |
|---|---|---|---|
logs.keep-days | Log lines: what apps, machines and jobs write, HTTP requests, network flows, DNS queries | 14 days | the realm, an organisation, a personal account |
audit.retention | The audit trail and the link log | 730 days | the realm, an organisation, a project |
compliance.sign-ins | Sign-in evidence, counted from when the session ends | 365 days | the realm |
billing.invoices | Invoices and credit notes | 7 years, at least | the realm |
billing.usage | Metered usage samples | 400 days | the realm |
licensing.records | Licences, usage reports and receipts | 7 years, fixed | the realm |
auth.unused-links | A link to a sign-in provider’s account, when unused | 395 days | the realm |
domains.contacts | A gone domain’s registrant contacts | 365 days | the realm |
jobs.history | Finished jobs and their logs | 30 days | the realm |
machines.screens | Records of screen sessions to machines | 365 days | the realm |
machines.deleted-scripts | Deleted scripts | 30 days | the realm |
api-keys.ended | Revoked and expired API keys | 30 days | the realm |
oauth.ended | Revoked and expired OAuth apps and grants | 30 days | the realm |
support.reports | Support reports, after they were sent | 90 days | the realm |
notices.kept | Notices | 90 days | the realm |
onboarding.evidence | What a person accepted when signing up | 3,650 days | the realm |
onboarding.invites | Sent invitations, after they ended | 30 days | the realm |
Only the modules your realm runs show their periods. A module you add later brings its own.
What the law fixes
- Invoices and credit notes must be kept seven years (Bokföringslagen 7 kap. 2 §). You may keep them longer; a shorter value is refused, naming the law.
- Licences, usage reports and receipts are kept exactly seven years. The policy is shown read-only, with the law as its reason.
Setting a period
Open Policies, the Retention tab, and choose Change on a row. Level picks the realm or one of your organisations, as for every policy (Policies).
- A period set for the realm applies to everyone without one of their own.
- Logs are kept per owner: an organisation or a personal account may have its own period. Below the realm, an owner may only shorten its retention; only an operator lengthens it.
- The audit trail keeps the longest period that applies along the way, so a project can’t keep less than its organisation asks.
- A period set at a level it doesn’t apply to is shown there, not set.
Every change is recorded in the audit trail, with who made it.
How deleting works
Each module deletes its own old records on its own schedule, reading the period when it runs. If it cannot read the period, it deletes nothing that round and says so in its log: deleting is the one thing that can’t be undone, so it never deletes by a value that may no longer apply.
The Compliance app’s What is kept lists every kind of record with its period, and links each one to its row in Policies.
What is not a retention period
Not on the tab, because they are not “how long records are kept”: how long a sign-in, a key or an invite lives while in use; caches; and counts like “the last 50 runs”. A few periods are still settings in deploy.json: the registry’s record of who pushed, an organisation’s history, an API key’s use log, network boot logs and machines’ licence ledger.