What exactly gets logged?

Critical and privilege-sensitive operations: destructive storage and network changes, process signals, service-level actions and the like. Routine reads are not noise in the trail.

Can an admin erase their tracks?

The trail is kept twice: in the system journal, which cannot be rewritten without root-level tampering, and in a separate file. Quietly editing history stops being trivial.

Are passwords or request bodies stored?

No. Secrets are never written to the trail; entries carry the actor, the action, the time and the result.

Where does the log live?

On the host itself, in the system journal plus a separate file. Nothing is shipped to an external service.

Does it use Proxmox accounts?

Yes. Atlas mirrors Proxmox users, groups and roles instead of inventing its own, so audit entries map to the same identities already managed in Proxmox.

Does logging slow the host down?

No. Only critical operations are recorded, not every click; the trail is a few lines per risky action.

Who changed what: an audit trail for the host

On a shared host, the hardest question after an incident is not what broke; it is who changed what before it broke. Atlas writes an audit trail for critical operations: the actor, the action, the time and the result, kept on the host in two places.

Why who did what is usually unanswerable

Stock tooling scatters the evidence. The PVE task log knows some operations, shell history knows others, and config edits often know nothing at all. Reconstructing an evening means stitching timestamps across all three.

Shared root access makes it worse. When several people can act as root, actions stop having authors; history files can be edited by the same power that made the change.

And most audits happen at the worst time: after an incident, under pressure, with the person who knows the answer possibly being the person who caused it.

Reconstructing an incident by hand

Without a trail, the usual investigation goes like this:

Read the PVE task log around the incident window and note what it saw.

Grep shell histories on the host, hoping nobody used a shared account.

Walk journalctl for the same window and try to match timestamps.

Diff current configs against the last backup to find silent edits.

Ask in the team chat who touched the host that day.

Write an incident note built on probably, and move on.

What Atlas writes down

Critical operations leave a trail as they happen, not a mystery afterwards.

Critical actions, recorded

Operations that change or endanger the system, destructive storage and network work, process kills, privilege-sensitive actions, are written to the trail as they run.

Actor, action, time, result

Each entry answers the four incident questions at once: who triggered it, what exactly ran, when, and whether it succeeded.

Two copies, tamper-resistant

Entries go to the system journal, which non-root users cannot rewrite, and to a separate file. Erasing tracks means defeating both.

Proxmox roles, respected

Atlas does not invent its own permission world. Who may do what comes from Proxmox users and roles, so the trail maps to real identities.

No secrets in the log

Passwords and tokens are never written. The trail records that an action happened, not the credentials that carried it.

Findings arrive on their own

The Watch sentinel raises critical findings by mail as they happen, so the trail is read before the incident, not only after.

Frequently asked

What exactly gets logged?: Critical and privilege-sensitive operations: destructive storage and network changes, process signals, service-level actions and the like. Routine reads are not noise in the trail.
Can an admin erase their tracks?: The trail is kept twice: in the system journal, which cannot be rewritten without root-level tampering, and in a separate file. Quietly editing history stops being trivial.
Are passwords or request bodies stored?: No. Secrets are never written to the trail; entries carry the actor, the action, the time and the result.
Where does the log live?: On the host itself, in the system journal plus a separate file. Nothing is shipped to an external service.
Does it use Proxmox accounts?: Yes. Atlas mirrors Proxmox users, groups and roles instead of inventing its own, so audit entries map to the same identities already managed in Proxmox.
Does logging slow the host down?: No. Only critical operations are recorded, not every click; the trail is a few lines per risky action.

Related entries

I revoked their access but they are still inside: a session is not the same as a permission You removed the permission, you even disabled the account, and the person can still do things. Nothing is broken: revoking access and ending a session are two separate actions.
Getting off root: the decision nobody forces on you and the one that pays most Working as root does not blow up one day. It quietly breaks two things: who the record points at, and where a wrong click stops. The fix is not disabling root, it is taking the daily work off it.
The audit record: the answer to "who did it", not "what happened" Monitoring tells you what happened, an audit record tells you who did it. Its value shows up on the days you hope never come, and if you do not have it that day, it never existed.