Air-gapped installation (Enterprise)

Air-gapped Enterprise deployments get installation packages. Everywhere else a machine is installed with one line from the internet (an install, end to end); a Linux machine with no route to the internet is installed from a package instead.

You receive one file — a .deb or an .rpm — carry it in by whatever means your estate allows, and install it with the tool your distribution already trusts. Nothing in this route reaches the network at any point. It also installs system-wide, into /usr/bin, where the one-line install puts the payload under a single operator's home or under /opt/saphan.

⚠ The packages are not signed today. Check the file's digest against the one you were given before you install it.

What a package contains — and what it deliberately does not

/usr/bin/saphan
/usr/bin/saphan-agent
/usr/bin/saphan-gateway
/usr/bin/saphan-server

That is the whole payload of a deb or an rpm: four binaries, mode 0755, and nothing else — no configuration files, no maintainer scripts, no service unit, and nothing that reads or writes a user's home.

That is a deliberate boundary rather than an unfinished package. Identity and configuration are made by verbs, per user; a package that reached into a user's home would break that, and a package that installed and enabled a service would start something on your host without asking. ⇒ Installing is one act and running is another, and the second one is yours.

Supervision is a verb, not a package artifact. Whether a machine runs Saphan Studio under its supervisor is decided after the install, by saphan service, so the package stays the same file on a host that supervises and on a host that does not. Whether state lives per user or machine-wide is decided at run time (Per-user vs system-wide state), never by anything the package put there.

The paths, and how they compare to a network install

The binary NAMES are identical on every route; the prefix is not, and that is by design. If you need a network install to land exactly where this package does, name the prefix:

curl -fsSL https://saphan.ai/install.sh | sudo sh -s -- --prefix /usr/bin

⚠ The mode of the directory matters. If the install directory is group- or world-writable, saphan refuses to start with custody-binary-unsafe rather than a permission error. The installer sets mode 0755 on each binary and on the install directory explicitly for that reason, and warns when it cannot.

⚠ And a package therefore installs no authorization server. saphan-oauth is not in the file list above, and no release artifact carries it at all — see Central servers. For an air-gapped site that is the sharpest consequence on this page: a host that must serve authorization cannot get that program by any route this site can describe, so plan the identity path of an air-gapped deployment around what Identity says the engine will accept, and settle it before the machines arrive.

Installing and upgrading on the target

sudo dpkg -i saphan_<version>_amd64.deb # or: sudo rpm -i saphan-<version>-1.x86_64.rpm
saphan version

Upgrading is the same command with the newer file — the binaries are replaced in place and the package version advances:

sudo dpkg -i saphan_<newer>_amd64.deb # or: sudo rpm -U …

Install first, then observe. A running process keeps the binary it started with; restart Saphan Studio's services after an upgrade, and anything you measure before that is measuring the old one.

What an air-gapped fleet still needs from you

The package gets the programs onto the machine. Four things it cannot bring, named here because an air-gapped plan that discovers them late is an expensive plan:

1. Setting the machine up from a terminal. ⚠ The browser setup page's account screen signs in to your Saphan account through the Saphan portal, which an air-gapped host cannot reach. Set the machine up with saphan install --workspace <folder> in a terminal instead — it needs no account (First run).
2. A CouchDB node. Saphan Studio keeps law and evidence in CouchDB; install it from your own mirror, then saphan infra databases creates the databases on it (CouchDB: the databases Saphan Studio creates). ⚠ The container route, saphan infra up couchdb, pulls an image, so on an air-gapped host it needs that image already present.
3. Somewhere for the agents' models to come from. An air-gapped fleet cannot dial a vendor's API, so its lanes point at model endpoints inside your own network, configured by address and by the name of the credential, never the credential itself (Configuration).
4. An egress policy that matches. Egress is closed by default and each backend's baseline names its vendor's hosts; a fleet that dials your own endpoints needs the installation's policy to say so (Egress control).

Proven, and not yet proven

• deb / linux-amd64 — built, contents and metadata inspected, dpkg -i installed, upgrade A→B verified swapping the binary, cleanly removable.
• linux-arm64 — built and confirmed to be a real ARM aarch64 static binary. Not installed on an arm64 Linux device.
• rpm — produced for both architectures, and its metadata and file list verified with rpm -qpi / rpm -qpl. Not installed on an rpm-family distribution.
• ⚠ saphan-server in the package — the deb and rpm carrying it have not been installed and upgraded end to end.