Bastillion: A Browser SSH Console With One Shared Application Key

The Problem: Per-User SSH Keys Do Not Scale Down

The ordinary way to give five engineers access to forty servers is to put five public keys in forty authorized_keys files. That is two hundred edits, and every departure turns into a hunt for stale keys on machines nobody remembers. The README frames Bastillion as a trusted third party rather than a password vault, and that framing is accurate: it does not store the passwords to your hosts after the initial key push. What it removes is the per-user key distribution problem. Users never hold long-lived keys to the target systems. Access is expressed as a profile assignment inside the application, and revoking that assignment removes reach immediately. The audience is a small platform or infrastructure team that wants bastion-host behaviour without operating a jump host plus a separate credential store plus a session recorder. It is not aimed at organisations that already run a full privileged access management stack, and the licence structure (free up to 8 systems, paid tiers above) makes that boundary explicit.

One Ed25519 Keypair Is The Whole Trust Model

On first startup, before anything else, Bastillion generates an Ed25519 keypair for itself. The README calls it the one key that ever gets pushed to your hosts, and it is shown in the console output and under Settings. Registration then works in two steps: an admin adds a host under Manage, Systems with user, host, port and the path to that host's authorized_keys file, and Bastillion authenticates once with a password or passphrase supplied at that moment. It pushes its own public key, and from then on connects with the key. Status flips to Success once the key is in place. This is the mechanism that makes the rest of the product coherent. Because every host trusts the same application key, disabling it once under Manage SSH Keys revokes access everywhere without touching target systems. The same property is the main risk: the application keypair is a single credential whose compromise is equivalent to compromise of every registered host. The README does not describe hardware-backed storage or an external KMS for that key, so treat the instance's filesystem as the security boundary and plan accordingly.

Profiles, Broadcast Terminals and Composite Scripts

Systems are grouped into named Profiles such as Production or Staging, and users are linked to profiles under Manage, Users. The README states that this assignment is the only thing controlling who can reach what. Terminals are opened under Secure Shell, Terminals: assigned users pick one or more systems and get live, resizable, xterm-based sessions side by side in the browser. Typing goes to every terminal marked active, which the README compares to tmux synchronised panes applied across hosts rather than local panes. The README also documents Composite Scripts, saved and re-run across a fleet. Broadcasting is the feature most likely to cause an incident: the same keystroke reaches every active terminal, so a destructive command typed with the wrong terminals selected runs everywhere at once. There is no described confirmation step or dry-run mode for broadcast input, and that absence is the sharpest usability trade-off in the product.

Session Recording, Retention and the Audit Switch

Everything typed and every byte returned in a terminal is recorded automatically, and managers replay sessions under Audit Sessions, filtering by user or system. Sessions that spanned multiple hosts replay side by side, with a text filter. The README notes that output streams into the page as it loads, so a session that dumped hundreds of megabytes of logs replays without the whole file being materialised first. Two configuration keys govern this. deleteAuditLogAfter defaults to 90 days, and recording can be turned off entirely with ENABLE_INTERNAL_AUDIT=false. That switch deserves scrutiny: the README positions session replay as audit-ready evidence for frameworks such as PCI DSS, HIPAA, SOC 2 and ISO 27001, but an operator who disables recording loses exactly the artefact those frameworks ask for. The default is recording on, which is the right default. Retention at 90 days is a starting point, not a compliance answer; check your own retention requirement against deleteAuditLogAfter before you rely on it.

Running It: Jar, Java 21, and the Config Keys That Matter

The README describes a self-contained jar run with java -jar, with HTTPS out of the box, and the repository's badges indicate Java 21, Jetty 12 and Jakarta EE 10. Prerequisites, download steps and build-from-source instructions live in the README's own sections rather than being reproduced here. The configuration surface that matters for an evaluation is small: ENABLE_INTERNAL_AUDIT toggles session recording, deleteAuditLogAfter sets retention in days, and the TLS and HTTPS section covers certificate handling. SAML 2.0 SSO is listed as new, with Entra ID, Okta and ADFS named as identity providers, and 2FA via Authy or Google Authenticator is documented. A v4 to v5 migration tool is mentioned for bringing over users, systems, keys and audit logs from an existing instance. One caveat about the README itself: the supplied text is truncated mid-sentence in the What's New section, so treat any claim sourced from that list as incomplete until you read the full document.

Licensing: Prosperity 3.0.0 and the Eight-System Ceiling

The README badge reads Prosperity 3.0.0, and the repository metadata reports NOASSERTION, which means GitHub's classifier could not map the file to a known licence. Prosperity 3.0.0 is not an OSI-approved licence, so this is source-available rather than open source in the strict sense. The practical consequence is stated plainly in the README: free at up to 8 systems, with paid tiers at loophole.company/pricing.html. For a homelab or a small internal deployment that ceiling is generous. For anything larger it is a procurement decision, not a technical one, and it should be settled before a team invests in the v4 to v5 migration tool. I am not a lawyer and this is not legal advice; read the licence text itself, particularly around redistribution and the definition of a system.

Where the Single-Key Design Breaks Down

The architecture assumes you want one application identity on every target. If your policy requires per-user keys on hosts so that a target's auth log names the individual, Bastillion works against you: the target sees the application key, and attribution lives only in Bastillion's own audit log. That is acceptable when Bastillion is the authoritative record and unacceptable when it is not. Two further limitations follow from the README. First, the keypair is generated on first startup and shown in the console, so key custody is an operational problem the documentation addresses only by pointing at Settings. Second, session recording is a storage commitment: a fleet with heavy terminal use will accumulate recorded sessions quickly, and the only documented control is deleteAuditLogAfter. There is no described tiering or external object storage for audit logs. Teams that need per-user attribution should look at Teleport, which issues short-lived certificates per user per session and therefore leaves an individual identity in each target's auth log. The difference in approach is the identity model, not the feature list: Bastillion centralises one key and records sessions to reconstruct who did what, while certificate-based access decentralises identity and keeps attribution at the target.

Editorial conclusion

Adopt Bastillion if you run a fleet of Linux hosts and want browser terminals, one-key revocation and session replay without buying a commercial PAM product. Do not adopt it if you need per-user keys on targets, if your compliance regime forbids a shared application key, or if you run more than 8 systems and are not prepared to pay. Before deploying, verify three things: the licence terms for your system count, whether the application keypair can be stored somewhere other than the instance's own filesystem, and whether ENABLE_INTERNAL_AUDIT and deleteAuditLogAfter match your retention policy.

Official sources

1. bastillion-io/Bastillion on GitHub
2. Issues
3. Project website
4. README
5. Releases