Trust is built with architecture, not claims
AtlasPVE is a security and operations layer installed next to Proxmox servers. This page explains openly how the product works, where the data lives and what happens if it is ever removed; a tool that asks for root owes accountability first.
A non-invasive architecture
AtlasPVE does not patch Proxmox core files. Every operation runs through the official Proxmox tools and APIs; the hypervisor is never forked and its packages are never replaced.
Authorization is not reinvented: who may do what is read from Proxmox's own permission system and enforced on the server for every request. Hiding a button in a panel does not count as authorization; the decision is always made on the server.
The component that runs as root is kept deliberately small: only execution and safety work runs as root; the interface and the decision layers never do.
Data stays with the customer
The product runs entirely on the customer's own server and does its job without internet access. Concretely:
Server inventory, VM lists and configuration never leave the host.
Metrics and charts are collected locally and stay local.
Logs and the audit trail live on the host; nothing is shipped to an external service.
No telemetry or usage analytics is collected.
Updates are fetched on request as signed packages; a package that fails verification is never installed.
When the internet goes away, the panel keeps working; the product does not depend on cloud services.
Six pillars of trust
Every claim on this page maps to something concrete in the product.
Clean uninstall
Removal is a single command and leaves no services behind. Creating no lock-in is a deliberate design decision.
Proxmox stays untouched
If AtlasPVE is ever removed, Proxmox keeps running exactly as before, because no core component was ever modified. Virtual machines, backups and snapshots stay right where they are.
Signed updates
Every update package is signed and verified before installation. If verification fails, the installation stops.
Small root, separated layers
The root component is a narrow execution core. The interface and the product logic live in separate processes without root; the attack surface is deliberately kept small.
Responsible disclosure
Security findings are received at security@atlaspve.com, handled with priority, and fixes are clearly marked in the release notes. Good faith researchers never face legal action.
No secrets in the logs
Passwords and tokens are never written to the audit trail. Records carry the action, not the credentials behind it.
Frequently asked questions
- What happens to Proxmox if Atlas is removed?
- Nothing. Since the core is never modified, VMs, backups and networking keep working as before; removal is a single command and leaves no services behind.
- Where does the data go?
- Nowhere. The product works without internet; inventory, metrics and logs stay on the server and no telemetry is collected.
- Why does it need root?
- Updates, storage and system operations require root. That is exactly why the root component is kept narrow; the interface and decision layers never run as root.
- How are updates verified?
- Every package is signed; the signature is verified before installation and an unverified package is never installed.
- How is a vulnerability reported?
- To security@atlaspve.com. Reports are handled with priority; if the finding is confirmed, keeping it private until a fix ships is kindly requested.
- How are security fixes announced?
- They are clearly marked in the release notes; the update screen shows which version carries security content.
- Is Atlas suitable for production environments?
- Atlas was not designed to replace Proxmox and it will not. That is not a shortcoming, it is the foundation the product is built on: the web interface, the shell and the terminals stay exactly as they are, data does not leave the host, and removing Atlas leaves not a single dependency behind. That is precisely the measure of production suitability, because a layer that leaves the infrastructure with its owner is reversible by construction. The component that runs as root on the server is open under AGPL; what it does can be read and audited, because trust is built by being inspectable rather than by being promised. From the first screen Atlas makes the overall distribution, the dependency chain and the direction the system is heading readable; the operations side waits in the same interface, and update, storage and network work is carried out with its impact visible beforehand.
Related entries
- Exposing the panel: what changes, and the path that changes the least The moment you put the panel on the internet, the login page becomes visible to everyone and automated attempts find it within hours. There are three paths, and the one that protects most never makes the panel visible at all.
- Choosing the identity source when adding a user: exists on the server, or only in the panel Proxmox knows two kinds of user: system accounts that really exist on the server, and accounts that exist only inside Proxmox. The wrong choice either blocks the login or opens more doors than needed.
- The console is a privilege: why it asks for its own permission A console looks like a screen, but it is a shell. And "can change settings" and "can open a shell" are two different powers; treating one as the other means handing out root.
- A separate key for automation instead of sharing a password: tokens and their limits Giving a script a password writes everything that person owns into a file. A token is a separate key: it can be revoked on its own, given an end date, and held to less authority than the account.