"No agents" is easy to say and worth being specific about, because "agent" covers a range of things and the distinction matters for anyone thinking seriously about their server's attack surface.
What an agent usually means
Most fleet-management and monitoring tools install a persistent background process on your server — an agent — that phones home to a control plane, listens for commands, or exposes a local API. It's convenient (the control plane can push to it anytime) and it's also a permanently running process with elevated privileges and, usually, outbound or inbound network access that has to be secured correctly forever, not just at setup.
What DeployOS does instead
Every DeployOS operation — deploy, check logs, run a backup, query database health — opens an SSH connection, runs the specific commands needed, and closes it. There is no DeployOS process resident on your server between actions. Nothing is listening for a connection from us; nothing calls out to us either. If DeployOS's own infrastructure disappeared entirely tomorrow, every server you manage with it would keep running exactly as it does today, because it was never structurally dependent on anything but SSH and Docker.
Why this is a meaningful security position, not just marketing
A resident agent is a standing attack surface: a vulnerability in it is a vulnerability in every server it's installed on, all the time, whether or not you're actively using the tool that day. An on-demand SSH connection only exists for the seconds it takes to run a command, authenticated with a key you control, using the same access model you'd use to SSH in yourself. It's the difference between "one more thing running on my server, forever" and "the same thing I'd do manually, automated."
Where your credentials actually live
SSH keys and any database/secret-provider credentials DeployOS needs are stored in your machine's OS keychain (macOS Keychain, Windows Credential Manager) — never transmitted to or stored on any DeployOS-operated server, because none exists in this part of the architecture. This is also why DeployOS's offline license verification (Ed25519, checked locally) matters as a matching design choice: the whole system is built to need as little trust in any DeployOS-side infrastructure as possible.
The honest limitation
SSH-only means DeployOS can't push real-time updates to you the way an agent-based system with a persistent connection can — auto-deploy-on-push, for example, works by polling "git ls-remote" on an interval rather than receiving an instant webhook, because a desktop app with no server-side component can't receive inbound webhooks. That's a real trade-off for a real security property, and it's the one DeployOS chooses.