KryllOS is a self-hosted product: you install it on your own server, and you are its sole user. No Kryll cloud holding your keys, no account to create, no password to manage.
This reality fundamentally changes the nature of the security model. The question is no longer "how to protect a multi-tenant service," but "how to protect a personal server that has no reason to be accessible from the outside." KryllOS's model responds with a simple principle: robust where it matters, lean where it's enough.
A solid security boundary
KryllOS is only accessible by you, via an SSH tunnel whose port remains permanently closed. It only opens after a port knocking sequence known to you alone. To an attacker scanning the Internet, your server doesn't exist: no open ports, no response, no visible attack surface.
This invisible-before-authentication approach applies a model designed in 2007 by the Defense Information Systems Agency (DISA) of the U.S. Department of Defense. Known as Software Defined Perimeter, or "Black Cloud," it was originally conceived to protect classified networks. It is today the foundation of Zero Trust architectures powering Cloudflare Access, Zscaler Private Access, and most modern ZTNA solutions.
No unnecessary friction between you and yourself
With a solid perimeter in place, the protections typically layered on the inside — HTTP authentication, sessions, rate limiting, local encryption of secrets — lose their purpose. If someone has crossed the SSH tunnel, it means they have your keys or a shell on your machine: from the system's perspective, they are you. Encrypting an API key with a decryption key stored right next to it doesn't change the cost of an attack.
KryllOS therefore chooses to be honest about what it actually protects, and to focus cryptography where it truly matters.
Cryptographic guarantees where they count
- Signed plugins: cryptographic signature verified before each execution, with auditing for the official marketplace.
- Sandboxed filesystem: all file operations pass through a validation layer that prevents a plugin or API call from escaping its dedicated folder.
- Hash-pinned dependencies: KryllOS and its components are distributed with a cryptographic manifest that allows verification that downloaded third-party libraries are exactly those tested by the team. A compromise of PyPI or an upstream repository cannot silently slip into an update.
- Isolated exchange credentials: your API keys are stored in a local SQLite database, accessible only by the KryllOS process itself.
Best practices on the user side
KryllOS handles what it can handle. The rest comes down to a few classic administration best practices:
- A strong SSH key (Ed25519, never passwordless) with a local passphrase.
- A port knocking sequence you don't share, and that you change if it has leaked.
- Exchange API keys created with minimal permissions (trading only, no fund withdrawal, IP restriction where the exchange allows it).
- Extra vigilance with plugins installed outside the marketplace: a third-party plugin is code that runs with your server's privileges. The official marketplace exists precisely so you don't have to do that analysis yourself.
A model suited to its audience
This isn't Binance or Coinbase. KryllOS doesn't hold the funds of millions of users, isn't publicly exposed on the Internet, has no attack surface to defend against continuously scanning bots. It's a personal trading station that, from the Internet, simply doesn't exist.
At this scale, the challenge isn't to build a defensive fortress. It's to shrink the attack surface until it becomes invisible, and to focus cryptography on the points that remain.
