Cloud data and security

The Cloud connection is narrow by design: the Opfield account can ask a connected installation a fixed set of questions and, with Allow remote management, run three actions. Everything else stays in your installation.

The connection

• Opfield opens one outbound WebSocket over HTTPS to https://account.opfield.dev and authenticates it with the credentials it received when it connected. No inbound port is opened, and Opfield does not follow redirects on this connection.
• The account pings the connection every 25 seconds. Opfield replaces a connection that has been silent for 70 seconds, and reconnects after a drop with a growing delay: from 1 second, doubling up to 60 seconds.
• In an installation with several app replicas, one replica holds the connection and the others report its state.
• When it connects, Opfield sends its installation ID (the one the license service knows), the installation name, the Opfield version, and whether remote management is on. While an administrator’s request for a sign-in client is waiting, it also sends the redirect URI it asked for and when. It also says that it takes requests to remove access (below). It sends this again whenever any of it changes.

What the account can ask

Request	What Opfield answers	Needs Allow remote management
State	Host name, uptime, Opfield version, CPU cores and usage, load averages, memory and disk totals and use, and the name, state, health, and start time of each of Opfield’s own containers	No
Services	The names of Opfield’s own containers	No
Logs	The latest lines of one of Opfield’s own containers, optionally since a given time	No
Update status	Current and latest version, update channel, whether an update is available, and whether one is running	No
Node token	A one-time node enrolment token, its expiry, and the install command, for a new node that Opfield creates as Nodes > Add Node does	Yes
Update	Starts the Opfield update to the available version, as Settings > General does	Yes
Setup code	A new first-admin setup code and its expiry; refused once setup is complete or the installation has users	Yes
Sign-in client	The account hands over an issuer, client ID, client secret, and redirect URI. Opfield takes them only while its request from Use Opfield account is waiting and for the same redirect URI (otherwise SSO_CLIENT_NOT_REQUESTED), adds the “Opfield account” provider, and turns OIDC sign-in on	No
Remove access	The account names people who lost access to the installation (removed from the team, their access removed, the installation moved to another account, or the account suspended) by their Opfield account ID. Opfield blocks their users; see Access removed in the Opfield account. Answers which users were blocked and which IDs have no user here	No

A managed installation also takes a sign-in client it did not ask for, as its provisioning file does: it replaces the client of an “Opfield account” provider in use, and otherwise only keeps it for Use Opfield account. If switching to the Opfield account would leave no administrator able to sign in, any installation only keeps the client.

The account can also replace the secret of the sign-in client it issued, on a managed installation and on any installation that received a client from it; Allow remote management is not needed. The installation applies the secret only while it signs in with the “Opfield account” provider; after an administrator removed that provider or replaced it with their own SSO, it refuses the secret with OPFIELD_ACCOUNT_PROVIDER_MISSING and changes nothing, and the previous secret stays valid. See Sign in with the Opfield account and Sign-in on a managed installation. An installation without a client from the account refuses the request.

Access removed in the Opfield account

When someone loses access to the installation in the Opfield account, the account tells the installation. Opfield blocks the users who signed in with that Opfield account, whichever OIDC provider the installation uses now:

• Their browser sessions end, open consoles and live views close as on any block, and their API tokens and OAuth and MCP access stop working. The tokens are kept, not deleted.
• Administration > Users shows Blocked by the Opfield account instead of the Blocked badge, and the user’s blockedBy is opfield_account in the API and MCP (admin for a block by an administrator).
• When the account gives the access back, the user’s next sign-in with the Opfield account unblocks them, recorded as user.opfield_account_unblock. A block by an administrator is never lifted by a sign-in. Unblock user lifts either block, and Block user on a user blocked by the Opfield account makes it a block by an administrator.
• The last active system administrator is never blocked this way; the answer to the account lists them as kept.

This needs no Allow remote management, and repeating the request changes nothing.

Readings come from Opfield’s own diagnostics: the host as Opfield sees it (or its container’s limits where the host is not visible) and the containers of Opfield’s own Compose project. Nothing extra is mounted for the connection. If Opfield does not run in Docker with access to its Docker socket, the container list and logs are unavailable and the answer says why.

The account cannot read or change your resources, configuration, secrets, nodes, workloads, Routes, databases, or their logs: Opfield answers only the requests above and refuses any other. The only setting it can change is the sign-in client described above, and the only users it can affect are those who signed in with the Opfield account, which it can block as described below. It answers at most eight requests at a time and answers with an error when a request takes longer than 14 seconds.

What is stored where

Where	What
Opfield’s database	The connection ID and secret (the secret encrypted with the master key, like other stored credentials), the account’s email and URL, and when it connected; the Allow remote management switch with who changed it and when; after a disconnect by the account, its email, URL, time, and reason; the sign-in client the account issued, if any (issuer, client ID, redirect URI, and the secret encrypted), kept apart from the OIDC provider for Use Opfield account; a waiting request for one, with its redirect URI and time
Opfield’s audit log	Each connect, disconnect, switch change, and request; see Audit log
The Opfield account	The connection code and the connection secret only as SHA-256 hashes, the installation’s ID, name, and version, and when it was last seen; the sign-in client it issued for the installation, if any

Connecting does not change the installation’s license or plan, which keep working through the license service as described in Plans and entitlements. For the other outbound connections Opfield makes, see What leaves a self-hosted installation.

If Opfield can no longer decrypt the stored secret, for example after the master key changed, it stops connecting and logs an error. Connect again with a new code.

Audit log

Every Cloud entry has the resource type cloud-link, and the audit log names its resource Opfield account with the account’s email:

Action	Recorded when
cloud.connect	Opfield connected, or failed to connect, with the source (a pasted code or a managed installation’s provisioning file)
cloud.disconnect	An Opfield user disconnected, and whether the account confirmed it
cloud.disconnected_by_account	The account revoked the connection
cloud.remote_management	Allow remote management was turned on or off
cloud.sso_revoke	The account removed access: the reason and the users it blocked, found blocked already, or kept
cloud.request	The account sent a request: its type, the container, log range, node name and type, or update version it named, whether it succeeded, and the size of the answer
cloud.enroll_file, cloud.managed_sso	Steps of a managed installation’s first start and of sign-in with the Opfield account: a sign-in client requested, request cancelled, client received or only kept, client secret replaced, and the client forgotten and the provider removed or kept when the connection ended; never with a key or secret

Actions and failed requests always get their own entry. Identical successful reads of the same type and container within 10 minutes of the first one are counted instead of written one by one: the first read has its own entry, and the repeats get one summary entry with their count and first and last time when the 10 minutes end, the connection stops, or Opfield shuts down. A node the account creates is recorded with the actor cloud-link. See Tasks, events, and audit.

When the account cannot be reached

Nothing in the installation depends on the connection. Opfield keeps running, serving traffic, and managing nodes; it keeps trying to reconnect, and the status shows reconnecting with the last error. The account shows the installation as offline after two minutes without a connection and cannot read or act on it until it reconnects.

If you disconnect while the account cannot be reached, Opfield forgets the connection anyway and warns you to disconnect the installation in the account too.

When the connection is removed

• Disconnected in Opfield: Opfield asks the account to revoke the connection, then forgets the connection ID, the secret, and the remote management switch.
• Disconnected or removed in the account: the account refuses the connection, and Opfield stops connecting, forgets the credentials and the switch, and shows Disconnected by the account.
• Switched to another account: the old connection is replaced at once, and remote management starts off.

In each case the installation, its resources, and its license are unchanged; connect again with a new code whenever you need to. After a disconnect, from either side, Opfield also forgets the sign-in client from the account and a waiting request for one. If the installation signed in with the “Opfield account” provider, Opfield removes it and turns OIDC sign-in off, unless no administrator could sign in then: the provider stays, the audit log records it with a warning, and Settings > Authentication > OIDC provider asks you to give an administrator another sign-in method and remove it.

Configuration export and restore

A configuration export restored on another host is not connected to any Opfield account: the connection of the exported installation is dropped, together with the sign-in client from the account and a waiting request for one. Connect the copy with a new code if you need it in your account.

An export of a managed installation comes back without its Opfield account sign-in, which works only at the cloud’s address: OIDC sign-in is turned off, password sign-in is on, and the owner gets a one-time link, valid 24 hours, to set a password. The installer prints the link, and a restore in the setup wizard shows it on its last screen. Users who signed in with the Opfield account need another sign-in method. The license stays with the managed installation: the copy starts on Community under a new installation ID.