Security & access control
How Roomler decides who may reach what — end-to-end encryption, roles and permissions, network ACLs, device-held gates, consent and audit.
Access control here is layered and default-deny, and the layers are owned by different parties on purpose: an organization, an administrator, a user and the machine itself each hold a gate, and any one of them refuses.
Security model
— Encryption, what the server can see, and where trust actually sits.
Users, roles and permissions
— Who can do what inside an organization.
Network ACLs
— Which machines may reach which machines, and on what.
Device policies
— Per-machine gates for remote commands, SSH and relaying.
Consent and audit
— Who gets asked, and what is recorded afterwards.
Signed releases
— How to know the software you installed is ours.
Self-host hardening
— What to get right when you run it yourself.
The one idea worth taking away
The last gate is always held by the machine
For the most powerful features — remote command execution, SSH, acting as a relay — the final decision lives in the machine’s own configuration, and the server cannot write it.
That is not redundancy. It is the property that makes the whole chain worth something: if the control plane were compromised, every server-side gate would fall at once. A gate the server cannot open is the only one that survives that.
The consequence is a real trade-off, stated honestly: turning these features on requires touching the machine, or explicitly opting that machine in to being remotely configurable. That is a cost, and it is deliberate.
Default-deny, everywhere it counts
| Surface | Default |
|---|---|
| Remote commands | Off, at four independent levels |
| SSH | Off, at four independent levels |
| Acting as a relay for others | Off |
| Being an exit node | Off, and needs a separate admin approval |
| Consent for a remote session | Ask — an absent setting means ask, not allow |
| SSH port forwarding on a device | Nowhere, until a destination is named |
An empty list means "nothing", not "everything"
Where the product distinguishes no policy configured from a policy that permits nothing, it keeps them distinct. Collapsing the two is how an access-control system silently becomes permissive.
In this section
Security model
What is encrypted, what the server can see, where trust sits, and which properties are structural rather than promised.
Users, roles and permissions
How membership, roles and permissions decide what someone can do in an organization — and which powerful ones are deliberately not granted by default.
Network access control
Control which machines may reach which machines on the mesh, on which ports and protocols — default-deny, enforced at both ends, and audited.
Device policies
The per-machine gates for remote command execution, SSH and relaying — four independent layers, each owned by a different party, all default-deny.
Consent and audit
Who is asked before a session starts, what is recorded afterwards, and why the record of a decision is kept separately from a machine's own account of itself.
Signed releases
Every Roomler artifact is signed — Authenticode on Windows, GPG and notarisation elsewhere — and the auto-updater verifies the publisher, not just the hash.
Self-host hardening
What to get right when running Roomler yourself — secrets, TLS, the origin setting, storage, backups and the checks worth doing after every upgrade.