Security & Trust

Built for the people whose job is to say no.

Terminalwire ships a command line to your users from software you can read: the server is open source and runs in your infrastructure, and the client is sandboxed like a browser, asking permission before it touches anything. Here's exactly how it holds up to a real security review.

Open, in your infra

The server is Apache-2.0. The code near your data runs on your servers.

Least privilege

The client can't touch a file, host, or the browser unless you granted it.

Fail-closed updates

Every client update is signature-verified against an offline root, or it doesn't run.

No user tracking

We never see the commands your users run, and we don't profile people.

The architecture

Trust that survives a code review

Not a trust-us page. Every claim below maps to how the software is actually built.

The server is open source

The Terminalwire server you add to your app is plain Apache-2.0 — read it, audit it, fork it, self-host it. It's a normal dependency your security team can review like any other, with a permissive license that leaves your own source entirely yours. The software that touches your users' data runs in your infrastructure, under your control, on your schedule.

The client is a trust boundary, sandboxed like a browser

The client runs on your users' machines, so we treat it the way a browser treats a website: default-deny. It cannot read a file, reach a host, run a subprocess, or open the browser unless that capability was explicitly granted for the specific origin it's talking to. Storage is isolated per origin. A server can ask; it can't reach past what it was given.

Auto-updates are signed and fail closed

Auto-update should meet a higher bar than convenience, so the client trusts exactly one thing: a public key compiled into it. An offline root key (kept in a vault, out of CI and off the network) signs a delegated release key; that key signs each release manifest; the manifest pins every artifact by SHA-256. The client verifies the whole chain and refuses anything that doesn't check out. A server you connect to can never push you code.

We can't watch your users, and we don't

The connection between the client and your server is direct — Terminalwire isn't in that path, so we never receive the commands your users run, their input or output, or any application data. There is no user account tied to an install and no attempt to link one to a person. We record a small amount of connection and licensing metadata (the server URL, an IP, the client version), never session payloads. We count installs, not people. No ad networks. No data sales.

Encrypted transport, your auth

Sessions run over an encrypted WebSocket (wss) in production. There's no separate credential store to breach: the CLI authenticates through your existing web app — your login, your sessions, your policies — because the command line is just another view of the server you already secure.

Tested to interoperate, so upgrades don't surprise you

Every server implementation (Ruby, Go, Elixir) and the client are validated against one language-neutral conformance suite — the same recorded sessions replayed byte-for-byte against each. "It works together" isn't a hope; it's a test that has to stay green. That's how a client upgrade doesn't quietly break a production deployment.