How 1ClickOps protects your server
The agent has full control of your server, so this is the guide to read before you trust it: what is checked, what is refused, what we never read — and what could still happen if 1ClickOps itself were broken into.
Every instruction is signed, and checked again
1ClickOps signs each instruction with a private key that exists only on our side. Your server holds only the matching public key, which can check a signature but cannot make one.
Before doing anything, the agent checks the signature itself. Then it checks that the instruction is one of the fixed actions built into it. An instruction that fails either check is dropped.
What the agent refuses even from us
The agent refuses these by itself, even when the signature is valid:
- An app that asks for control of the server: full privileges, a folder of the server’s own disk, the server’s network, or control of Docker. If the agent cannot check what an app asks for, it refuses.
- Acting on software 1ClickOps did not put there, even when it has the same name as one of our apps.
- A new version of the agent that is not signed with our update key, or is older than the one running.
- For software that was already on your server and that you asked 1ClickOps to look after: deleting it, changing its network, or reaching the server through it.
What we never read
- When 1ClickOps looks at what already runs on your server, it records names, addresses and health. It never reads passwords, keys, tokens or the values of settings. It notes only that a settings file exists.
- The passwords used to back up your databases stay on your server. They are never put in an instruction.
What we do hold: the settings and secrets you type into 1ClickOps, stored encrypted, and whatever your apps print while building.
Key sign-in, set up with you
On the Security page, Set up key sign-in makes a key pair in your browser. Both files go only to your own download; neither is sent to 1ClickOps. You put the key on the server yourself, from your computer, because 1ClickOps never adds SSH keys. Turn off password sign-in is offered only after the server has seen your key sign in.
Installing updates
The Security page counts the updates waiting, and the security fixes among them. Install updates installs them while your apps keep running. Docker is left out, because updating it restarts every app. The server is never restarted: if it needs a restart, the page says so, and you do it from your hosting provider.
Changes that undo themselves
A change to sign-in or the firewall puts itself back after 5 minutes unless you press Yes, keep it, which you can do only after ticking that you tried. The server does this by itself. Opening a port is the one such change with no undo.
Buttons only where they were proven
A Security button appears only on systems where it was proven on a real machine. Elsewhere, one line says what is not offered. On a system we have not tested, the page only looks.
If 1ClickOps itself were broken into
We do not promise that a break-in at 1ClickOps would be harmless. Someone in control of it could:
- Sign instructions that your server would accept, for any action on the agent’s fixed list. That includes deploying, changing, restarting and removing the apps 1ClickOps runs, and the server settings on that list, such as the firewall.
- Use the settings and secrets you saved with us.
They could not:
- Make an app take control of your server. The agent refuses that whoever signed the instruction.
- Replace the agent with a tampered one. Updates are signed with a key that is kept offline and is not on our servers.
- Go past the agent’s built-in limits for software you asked us to look after, or do it quietly: taking on such software is recorded and emails the workspace’s owners and admins.
- Find your other software’s secrets with us. They were never collected.