Who controls what

The two modes run the same image; they differ only in who holds the configuration, the secrets and the host.

	Customer-operated	Privately managed
Host, network, TLS	Your IT	The operator you contract, on infrastructure you name
Storage (database, stored files, backups)	Your volumes and backups	The operator’s volumes; backups delivered to you on request
Compute (calculations, runners)	Your host	The operator’s host
Models (AI use)	Only providers you configure; nothing by default	The same: only providers you approve
Access (who may read what)	Project administrators in your organisation	Project administrators in your organisation: the first administrator in config.json is your nominee; the operator places that first token and hands it over, and it should be replaced after first sign-in (a new token revokes the old one)
Operations (upgrade, restore, members)	Your operator, with ophiolite-ops	The contracted operator, with ophiolite-ops
Exit	Portable bundles and backups, any time	Portable bundles any time; a backup or a project move to your own deployment on request
What the operator can see	Your operator, who runs the host, can read the database and the stored files; inside the product only what a project administrator grants	The contracted operator, who runs the host, can read the database and the stored files; inside the product only what a project administrator grants
What Ophiolite (the vendor) sees	Nothing: no telemetry, no vendor account	Nothing: no telemetry, no vendor account

What an operator can see. Whoever runs the host can read the database and the stored files: that is true of any server software. What Ophiolite adds is that access inside the product is by explicit grant, every change is recorded in the activity history, and a project can be moved or exported without the operator’s cooperation in the data format (bundles are readable without Ophiolite).

What Ophiolite (the vendor) sees. Nothing: the image sends no telemetry and needs no vendor account.

What the image contains. The image lists its own dependencies in /opt/ophiolite/DEPENDENCIES.json (read it with docker run --rm --entrypoint cat <image> /opt/ophiolite/DEPENDENCIES.json): the operating-system packages, the Python distributions and the shared libraries the server and worker load, each checked against the image by the release qualification. The list also covers the libraries built into the binaries, which come from their build, and the third-party code in the Workspace and site bundles, which comes from those builds’ licence output. Each entry names its licence and the licence texts the image carries: the operating-system packages’ copyright files, the Python distributions’ own licence files and those of the libraries their wheels bundle, and the native and web texts under /opt/ophiolite/licences/. The release qualification fails an image where any licence is unresolved or any text is missing or changed. The code that compiled Python extensions link statically is listed too, with its licences and texts, per package and version; the qualification fails an image with a compiled extension that this list does not account for.