A government client's server is not my server. On-Prem Manager (OPM) can now reach one in three ways, so the useful question for each is who can turn it off.

OPM is the open-source tool I built to run on-premise Docker deployments: a cloud console, and one Go agent per server with its own GUI. Three things changed.

1. The browser tunnel is end-to-end encrypted

Some sites have no internet at all. For those, the agent borrows the browser of the person using its GUI: the tab fetches from the cloud on the agent's behalf.

Until this change, every request and response passed through that tab in clear. That included commits with secret values, and on a LAN the agent GUI may be plain http.

Now the agent seals each request to an X25519 key on the cloud, and that key has to be certified by a release key pinned in the agent's config. The cloud answers with an AES-256-GCM stream. The tab carries ciphertext.

There is no fallback. If the key is missing or the signature is wrong, the call fails and the reason shows on the Internet page. An agent with no pinned key can be told to run in clear, and that is logged every time a tunnel starts.

The security review changed the design once. A replayed request gets a second answer under the same key, and with the plain design that reuses key and nonces, which opens the first answer. So each response now starts with a random 32-byte salt that derives its own key.

The tab can still see that a call happened, its size and its timing, and it can drop calls. Relays between agents on the mesh are signed, not encrypted. Agents older than this stay in clear until they are updated and have the release key, which the install script adds and opm-agent upgrade does not.

2. The agent GUI on the cloud's own domain

Each site's agent GUI now opens from the cloud console, at a path under OPM's own domain:

<cloud>/app/deployments/{deploymentId}/remote/{siteSlug}/_opm/…

You log in to the cloud once. There is no agent key to find and no extra port for the client to open, because the site asks the cloud for work over outbound HTTPS and the cloud never calls a site. Every action is recorded on the site under the person's cloud email, and the GUI shows "through the cloud".

This one is on by default. The client switches it off in the agent GUI on the site, and open remote sessions end at once. A remote session can't flip that switch; the call answers 403.

3. Port tunnels

A container port, the site's edge or a TCP port on the server can be forwarded to a port on the cloud's VM. It carries raw TCP, so a website, an API or a database client all work, and a site with no cloud route of its own can be served through a peer.

You add a tunnel in the console, and it does nothing there. It stays off until someone switches it on in that site's agent GUI, under Agent › Tunnels. Each site keeps its own switches.

Two limits, because the switch is only as good as what sits around it:

  • The tunnel switch also works from the agent GUI opened through the cloud. So a client who wants the decision to stay on their side should turn the remote GUI off as well.
  • The public port has no login of its own. Whoever reaches it reaches the target, so the target's own auth is what stands there.

Why the switches sit on the client's side

Local deployment is why these clients buy Envizom in the first place. They keep the data, and now they also decide how much of a path to it exists. If a client isn't comfortable with any of this, the same agent GUI turns it off and the deployment keeps running without it.

The code is at github.com/Panth977/on-premise-manager, Apache-2.0. The sealing is in SPEC-final §9.10, the two tunnels in §21 #118 and #125.