Deploying and operating atmon
This documentation is for the person who installs atmon, runs it, and administers it for an organization. It assumes you hold the machine or the contract. If you are the person handing work to an assistant, the documentation you want is the product documentation at atmon.ai/docs.
An enterprise runs atmon in one of two shapes, and both are covered here.
On our cloud. atmon runs on our infrastructure with enterprise controls, and your administrators work in the console at enterprise.atmon.ai/console. You install nothing. The administration pages apply to you; the deployment pages do not.
On your machines. atmon runs inside your network, on your storage, sealed with your key. No data leaves the building. Every page here applies to you, and the software is downloaded with the product rather than served from any atmon address.
Where to go
| If you want to | Read |
|---|---|
| Get a node answering for the first time | First boot |
| Make the first account on a fresh node | Claiming a deployment |
| Give your administrators a browser interface | The console on your node |
| Move to a newer version without losing a call | Upgrades |
| Survive the loss of a machine | Backups and restore |
| Reach an internal system that has no public address | The relay |
| Close the deployment down before it faces a network | Hardening |
| Look up an operator command | The operator CLI |
| Decide who may do what, and prove what was done | Administration |
What a deployment is
One process, one directory. The process serves the API, the MCP endpoint, the sign-in callback, and inbound messages from connected apps on a single port. The directory holds every database it writes: the catalog, the tenants, the connected credentials, the receipts, the collections a job produced, and the audit record.
That shape carries one hard rule. Two processes writing the same directory from two machines is data loss rather than availability, so running a second node is a design decision and not a deployment setting. What one node with a practised restore gives you is recovery in minutes. What it does not give you is staying up through a reboot, so an upgrade is a short announced window.
What we never hold
On a deployment inside your network, we hold nothing. The vault key that seals every stored credential is minted on your machine and never sent anywhere. The databases are files on your storage. The sign-in applications are registered under your own accounts with each provider. The outbound calls leave your network and reach the provider directly.
The list of what we never see on either shape of deployment is on the security page.
Where this stands
atmon is in beta. The paths described here are real: a node starts, seals credentials, runs the gates, records every call, and refuses what it should refuse. Live provider accounts are beginning. GitHub has approved atmon as an application its users can connect and is the only one so far, so every other connector is still proven against a stand-in service rather than against a real inbox or a real payment account.
Single sign-on is not built. It is on the enterprise roadmap, the role model that would sit under it is built and shipping, and until it lands your administrators sign in with email.
Read that boundary before you plan a rollout around it.