> ## Documentation Index
> Fetch the complete documentation index at: https://docs.certgov.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Platform Architecture

> How CertForge is built — regional data sovereignty, active node pools, and the full service stack.

CertForge runs as a multi-region platform. Each region is an independent **data sovereignty boundary**: your API token determines which region your org lives in, and all data — certificates, private keys, audit trail, org configuration, and approval history — stays in that region. No cross-region data flows occur.

<img src="https://mintcdn.com/certforgellc/yyg0e5fxwfyfoBuc/images/platform-architecture.svg?fit=max&auto=format&n=yyg0e5fxwfyfoBuc&q=85&s=d4f178416f714f3da595c99a7e58a842" alt="CertForge Platform Architecture — client environments (cert-manager, ACME, REST, certforge-connector, certforge-discovery), regional data sovereignty boundaries (US East, EU West, APAC), active node pools, AI server, and external services" width="1100" height="1460" data-path="images/platform-architecture.svg" />

## Service stack

Each node in every region runs the full service stack:

| Service                         | Role                                                      |
| ------------------------------- | --------------------------------------------------------- |
| **REST API · ACME Server**      | Ingests certificate requests via REST or RFC 8555 ACME    |
| **Policy Engine**               | Evaluates requests against Domain Trust Profiles (DTPs)   |
| **Approval Store**              | Tamper-evident approval chain using TRE hash chains       |
| **Certificate Executor**        | Submits approved requests to the configured CA            |
| **Audit Trail**                 | Immutable log of every request, decision, and issuance    |
| **Platform UI · Notifications** | Web dashboard and outbound alerts (email, Slack, webhook) |

## Data residency

| Region             | Endpoint            | Data boundary                                                                             |
| ------------------ | ------------------- | ----------------------------------------------------------------------------------------- |
| **US East**        | `app.certgov.app`   | All org data stays in US East. PostgreSQL primary + streaming replica, both in-region.    |
| **EU West (GDPR)** | `eu.certgov.app`    | All org data stays in EU. Independent PostgreSQL — no replication to US or other regions. |
| **APAC**           | Coming soon         | Independent region, same sovereignty model.                                               |
| **Self-hosted**    | Your infrastructure | You control the host. All data stays on your own servers.                                 |

Your API token is scoped to a single region at account creation time. There is no mechanism to move data between regions — isolation is enforced at the token level, not just by policy.

## Self-hosted deployment

Self-hosted instances use the same binary and service stack as the cloud regions. The only difference is that you provide the host, database, and TLS termination. Governance features, approval workflows, and audit trails work identically.

See the [self-hosted setup guide](/self-hosted/systemd) for installation instructions.

## certforge-issuer (Kubernetes)

The `certforge-issuer` controller runs inside your cluster as a cert-manager external issuer. It intercepts `CertificateRequest` objects and routes them to CertForge for policy evaluation before any certificate is issued.

See the [cert-manager integration guide](/guides/cert-manager) for setup instructions.