Triunnia Labs

The First Service You Create

The Application Api is the first microservice you set up in Arch — and the one everything else depends on. It carries two essential responsibilities: it is the authorization authority for the entire platform, and it is the keeper of the Guardian, which manages the Bootstrap Key that brings the entire platform to life. No other Arch service starts without it, and no service communicates without its approval.

Zero-Trust Authorization

No Service Earns Trust Automatically

Every Service Must Register

The Application Api enforces a hard rule: no service may communicate with another without first registering with the Application Api and being granted explicit permission to do so. This applies equally to Arch's own built-in APIs and to any custom services you bring into the platform. Every participant in your distributed application must earn its place.

Cryptographic Enforcement

Authorization is a cryptographic guarantee woven into every inter-service call — not a policy checked at the boundary. When the Application Api grants a permission, it issues unique cryptographic keys to the requesting service. Every subsequent call requires those keys. The system has no bypass.

Build On It

Authorization Infrastructure You Don't Have to Design

Every Custom Service Inherits It

When you extend Arch with custom microservices, those services use the same Microservice framework that every built-in Arch API uses. That means your custom services automatically inherit the same Application Api-based authorization model that protects the rest of the platform. Register your service once, grant it the permissions it needs, and the Application Api handles the rest. Your team never has to design, implement, or maintain inter-service authorization from scratch.

Focus On Your Application

Inter-service authorization, key lifecycle management, HSM integration, sealed startup behavior, and cryptographic enforcement of permissions are complex engineering problems. Arch solves them once, to a high security standard, so that you can focus entirely on what differentiates your product. Every hour your team saves not rebuilding this infrastructure is an hour invested in the application your customers care about.

A Platform That Grows With You

Because the Application Api sits at the authorization layer of the entire Arch platform, every security improvement to Arch propagates automatically to your application. Planned enhancements — quantum-resistant encryption, automatic key rotation, and expanded HSM support — will flow through the Application Api and protect your distributed application without requiring changes to your code.

The Guardian

An Optional Layer of Hardware-Backed Security

Can Start Sealed

If enabled, the optional Guardian feature starts the Application Api in a Sealed staste. In this state, the Bootstrap Key — the root of trust for the entire platform — is not in memory. The Application Api denies all authorization requests and returns an unavailable response to dependent services until an authorized operator explicitly unseals it. This prevents the Bootstrap Key from being exposed automatically at startup, even if the server is compromised at the moment it restarts.

With Hardware Security Module

The Bootstrap Key is stored in a hardware security module and is never written to disk. To unseal the Guardian, an authorized operator authenticates through the Control Panel using HSM credentials. The Guardian retrieves the Bootstrap Key, holds it in memory, and transitions to an Unsealed state.

If the HSM detects physical tampering, it zeroizes its contents — the Bootstrap Key cannot be extracted by force. For maximum security, the HSM can be held by a separate individual from the server operator, so bringing the system online requires both parties.

This model is recommended for production deployments, particularly in security-conscious and regulated environments.

Without Hardware Security Module

HSM integration is optional. When not configured, Application Api starts up as normal, as does your distributed application.

This model is appropriate for most deployments, including low-risk internal deployments or organizations beginning their Arch adoption before acquiring hardware.

Development Mode

For local and testing environments, the Guardian ships with an HSM simulator. The simulator provides the same interface as the YubiHSM 2 without requiring physical hardware, allowing developers to build and test against the full Application Api behavior before deploying to production.

Connected by Design

Application Is the Authorization Root for the Entire Platform

Every Arch Service

Every built-in Arch API — Keys, Tokens, Email, Users, Comments, Entity, Files — registers with the Application Api and is granted explicit authorization to operate. None of them start without it. None of them communicate without its approval. The authorization contract is uniform across the entire platform.

Your Application

Custom microservices register once with the Application Api and inherit the same authorization infrastructure that protects the built-in services. Inter-service trust is enforced cryptographically from the first call. Your team never designs or maintains this layer — it is already built.