Deployment models
Four ways to run it.
Three of them on your machines.
A setup on our cloud that your organization is alone in. Or your own cloud account, a private subnet with no public entrance, or a machine on your own floor. The software is the same in all four; the boundary moves.
The four
Pick the one your policy already allows
The first column is the offer we run for you. The other three are the same software on machines you own, and what separates those three is where the machine sits and how your people reach it.
| On our cloud | Your cloud | Your private subnet | Your building | |
|---|---|---|---|---|
| Whose machine | Ours, and your organization is alone on it | An account you own, in the region you choose | A subnet with no route in from the internet | A server on your own floor |
| Who operates it | We do | Your team, under your change process | ||
| Where people sign in | enterprise.atmon.ai/console, with an email | Your usual entrance for an internal web tool | Over the network your staff already use | The office network |
| Who holds the key over the store | We do, and no path reads a secret back out | You generate it, you hold it, and no path reads a secret back out | ||
| What has to be open | Nothing. Your people reach it in a browser | Outbound to the apps you listed | ||
| What we can reach | The machine we run for you | Nothing | ||
| Where the record lives | On the node we run, exported from your console | A table in your own database | ||
If the apps a department works in are themselves internal, the relay is how either offer reaches them, and it dials out from your side in both.
On our cloud
Where a hosted setup sits
One node, running your organization's work and nobody else's. Your people and your assistants reach it from your own network, and it reaches the apps you connected on your behalf.
- The node holds your work and nobody else's. Every read is scoped to your organization, and where the agreement warrants it the node itself is yours: your own address, nobody else on it.
- The store is sealed with the key that seals our deployment. No surface returns a stored secret, so a secret cannot be read back out by anybody, including by us.
- The record is complete on the same terms as it is on your own machines, and your administrators export it from enterprise.atmon.ai/console rather than asking us for it.
- Nothing is installed and nothing is opened. Your people meet it in a browser, and your assistants and your own services reach it out of your network.
In your building
What runs where, on your own machines
Everything with your name on it sits inside your perimeter. Two lines cross the boundary and both are outbound.
- The software is one process with its files under one directory. It holds the connections, checks the rules and writes the record.
- The database is yours. Every action, every refusal and every approval is a row in it, and retention is your setting.
- The key is generated by you and given to the process at start. Nothing we run can open the store it seals.
- The console is a page your people open inside your network, pointed at your deployment rather than at us.
Internal systems
Reaching something with no public address
Plenty of the systems a department lives in have no address on the internet: the warehouse system, the claims desk, the thing written in 2009 that finance will not give up. Either offer reaches those through a relay.
- You register the relay in the console and it is handed its credential once, at that moment, in the same screen a key is minted in.
- It is listed with the connections beside the apps, because from a project's side it is the same statement: this is what we can reach.
- Revoking it is one row. Work already in flight ends and says how far it got; nothing new goes down that path again.
- It matters most on our cloud. Reaching into a network we are not in, without that network opening anything, is the reason the relay exists at all.
Running it yourself
What your team operates, in your building
On our cloud this section is our work rather than yours. On your own machines it is a process, its files under one directory, started with one secret. That shape comes with one hard rule: two processes writing the same files from two machines is data loss rather than resilience.
For most deployments that is the right trade. One machine with continuous backup and a restore your team has actually practised comes back in minutes.
What it does not give you is staying up through a reboot, so an upgrade is a short announced window rather than a rolling one.
- The key. You generate it and you keep it. Losing it means losing every connection your people made, and no copy of it exists anywhere else.
- The sign-in applications. You register your deployment with each provider yourself, so the consent screen your staff see names your company.
- Backups. A machine holding every connection your organization has made is worth what its last restore drill proved.
- The operator commands. Claiming a fresh deployment, minting the first key and reading the outbound traffic audit happen on the machine, not over the network.
The short list
What a deployment on your machines never asks for
- No inbound hole Nothing has to accept a connection from us, on any port, in any model. If your firewall never changes, the deployment still works.
- No access for us No standing account, no support tunnel, no shared credential. When your team wants help, they bring us what they choose to bring.
- No copy of your data Nothing is mirrored, staged or forwarded for processing. The never-see list is the whole statement of it.
- No agent on laptops Your people use a browser. Nothing gets installed on a workstation and nothing watches what anybody types.