Nothing leaves your network.

Octotor is self-hosted: one VM, yours, holding your data and your credentials. For a product that touches every machine you manage, "trust us" is not an answer — so this page answers the real questions concretely: where secrets live, what traffic leaves the VM and when, and how to verify that what you install is what we built.

Where your credentials live

The Credentials Vault stores every secret encrypted with AES-256-GCM inside the instance's own PostgreSQL database. The key is unique to your instance, and every encryption uses a fresh random nonce. The key is generated at install, lives only in the VM's environment file, and is never written to logs, jobs, or the database. Nothing outside your VM can decrypt the vault — including us. Inside it, the key is readable by root, as it is on any self-hosted system: treat access to the VM as access to the vault, and protect it accordingly. If the key is lost, the vault stays sealed. That is the design, not a limitation.

What leaves the VM

That is the complete list. There is no telemetry, no analytics, no usage reporting, and no license phone-home.

Licensing works offline

The license is a signed file (Ed25519), verified locally on your VM against a public key baked into the images. It is bound to your install — there is no activation server, no periodic check-in, and no network dependency. Air-gapped installs work: the license travels as a file, in both directions.

Hardened by default

• Containers run with a read-only root filesystem, all Linux capabilities dropped, no-new-privileges, and a non-root user.
• One inbound port on the whole VM: the TLS console. Everything else only reaches out.
• The application talks to PostgreSQL as a restricted role, with parameterized queries throughout.
• An optional host-level egress allow-list locks the containers' outbound traffic to a list you control (opt-in at install or later).

Ports and protocols

Reaching the console

The console is the only inbound surface, so it is protected accordingly: local accounts with role-based access, optional multi-factor authentication (TOTP) that can be enforced instance-wide, per-action passwords on sensitive operations, rate-limited logins, and API tokens that are scoped and revocable. Details on request.

Privilege model

Octotor uses the accounts you give it, stored per-customer in the vault. Monitoring needs no credentials at all (ping, TCP, SNMP read community). Inventory and remediation use what the job genuinely requires — a WinRM account for Windows collection, an SSH user for Linux. In the console itself, role-based access separates admins, operators and viewers, and every user can be scoped to specific customers.

Backup and recovery

A nightly job dumps the database; restoring an instance takes the dump plus the environment file, which holds the vault key. Keep the environment file in your own secret store, separately from the dumps — a database backup alone cannot open the vault, and that is deliberate. Lose the VM and you rebuild from the dump + key on a clean install. The license is bound to your install: rebuild on new hardware and we reissue it at no charge — normally within one business day (licensing@octotor.com).

Read the source

Octotor ships with readable source code, and the license grants an explicit right to inspect it on your instance — security review, compliance verification, understanding exactly how it works. For a product that holds credentials across your whole client base, you shouldn't have to take this page's word for anything: you can read it.

Verify what you install

Two signatures cover the supply chain. The publisher key is served from a separate origin to the release bundles, so no single compromised host can serve you both a forged artifact and a matching key. Fingerprints are published here; check them before you trust a key.

Fingerprints are the SHA-256 of the public key in DER form. To reproduce the publisher-key fingerprint from any machine:

Install bundle — every release ships with a detached signature. The publisher key (octotor-release.pem, fetched above):

Container images — every image is Cosign-signed; the installer verifies each one before anything runs, and refuses the install on any mismatch. The signing key ships inside the install bundle as octopus-pub.key (kept at /opt/octopus/octopus-pub.key on an installed system) — the same openssl command reproduces its fingerprint:

The verified install steps are on the deploy page; system prerequisites are on the requirements page.

Reporting a vulnerability

Security disclosures go to security@octotor.com — every report gets a response.

Further detail on architecture, security design and deployment is available on request — security@octotor.com.