Triunnia Labs

Securely Store Secrets

The Keys Api is Arch's dedicated secrets vault. Every encryption key, connection string, API credential, and sensitive value that must not live in a regular database passes through the Keys Api. It stores nothing in plaintext, exposes nothing unencrypted, and grants access to nothing without authorization.

A Vault, Not a Database

Secrets Belong in a Place Built for Secrets

Separation by Design

Application databases store the data your application works with. The Keys Api stores the secrets that protect it. These two categories of data have fundamentally different security requirements — they warrant fundamentally different storage. The Keys Api provides that separation as a first-class platform concern, so that every application built on Arch inherits it without additional effort.

Each Application Owns Only Its Own Secrets

Keys are organized by application, category, and name. A microservice can retrieve only the secrets belonging to its own application — access to another application's vault is structurally impossible. This multi-tenant isolation is the default, not a configuration option.

Always Encrypted

No Plaintext at Rest. No Plaintext in Transit.

Encryption Is Not Optional

Every key and every value stored in the Keys Api is encrypted before it reaches the database. This is not a feature you enable — it is the only mode of operation. HMAC-SHA512 integrity verification, AES-CBC encryption, and AES-GCM encryption (when using the Bootstrap Key) both with SHA-256 hashing are applied uniformly to all stored material. A database breach yields ciphertext.

The Protected Envelope

All communication with the Keys Api uses Arch's Protected<T> framework. Requests arrive encrypted, data is processed in protected form, and responses leave encrypted. Nothing about the secrets you store is visible to network observers, and nothing is exposed to any layer that does not hold the appropriate keys.

The Root of Encryption

Every Encrypted Operation in Arch Traces Back Here

The Foundation Other Services Depend On

The Keys Api is a root service — it has no dependency on any other Arch API. Other services depend on it. The Users Api stores per-user encryption keys in the Keys Api, enabling Arch's zero-knowledge authentication architecture. Any custom microservice that needs to store sensitive credentials, rotate connection strings, or maintain encryption material across restarts uses the Keys Api to do so.

Platform Encryption

Per-user encryption keys generated by the Users Api are stored in the Keys Api. This is how Arch achieves zero-knowledge user data protection at the platform level — the Keys Api is the silent partner in every encrypted user record across the system.

Application Encryption

Your custom microservices store their own secrets in the Keys Api — database credentials, third-party API keys, certificates, and anything else that must survive restarts without appearing in configuration files. The structure is the same. The isolation is the same.

A High-Value Asset Treated as One

Because the Keys Api holds the secrets that protect the rest of the system, it warrants dedicated attention in your deployment architecture. Deploy it behind strict network segmentation and restrict access to services that explicitly require it. The Keys Api protects everything placed in its care — your deployment model should protect the Keys Api itself.

Fast When It Matters

Secrets Retrieval That Does Not Slow Your Platform Down

In-Memory Caching

Secrets that services retrieve frequently are cached in memory for fifteen minutes. The Keys Api resolves the cache first and reaches the database only on a miss. Encryption keys needed on every request — per-user keys, connection strings for active pools, API credentials for high-frequency calls — are available at memory speed without sacrificing the encryption guarantees that protect them at rest.

Connected by Design

Keys Is the Silent Partner in Every Encrypted Operation

Platform Services

The Users Api stores per-user encryption keys in the Keys Api — it is how Arch achieves zero-knowledge user data protection at the platform level. The Entity Api and Comments Api supply per-row encryption keys that are best managed here. Rotating a platform encryption key means updating the Keys Api, not redeploying services.

Your Application

Custom microservices store database credentials, third-party API keys, certificates, and any value that must survive restarts without appearing in a configuration file. The structure is the same as the platform services that depend on it. The isolation is the same.