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

# Deployment and security

> Where REM runs, what stays under your control, and the operational guarantees REM is built around.

## Deployment modes

REM runs wherever the security boundary requires. The same control plane supports every mode.

<CardGroup cols={2}>
  <Card title="REM-managed cloud" icon="cloud">
    REM operates the deployment in an isolated environment.
  </Card>

  <Card title="Dedicated VPC" icon="network-wired">
    Single-tenant infrastructure with isolated networking and keys.
  </Card>

  <Card title="Customer cloud" icon="building">
    Deployed into your cloud account, under your policies.
  </Card>

  <Card title="On-premises" icon="server">
    Deployed inside your own data centre.
  </Card>

  <Card title="Embedded / OEM" icon="puzzle-piece">
    REM runs as the white-label backend inside a vendor's own product.
  </Card>
</CardGroup>

Private deployments keep secrets, retention, networking, observability, and upgrades under customer control.

## What stays with you

REM does not own customer funds, balances, wallets, keys, custody, issuance, regulated execution, or the final action.

* **Signing** goes through an interface to your KMS, HSM, vault, or custodian. Local keys are used only in development.
* **Execution** of regulated actions remains with you, your bank, your custodian, or your licensed provider.
* **Data** is limited to the participant view you authorise, processed inside the boundary you define.

## Control plane

* RBAC, service identities, secret management, and least privilege
* Data retention, residency, tenant isolation, and participant visibility controls
* Versioned schemas, mappings, policies, and workflows
* Metrics, logs, traces, alerts, incident evidence, and replay controls
* Encryption, isolated environments, and reproducible deployments

## Correctness guarantees

* At-least-once ingestion with exactly-once **business effects** through idempotency
* Recovery without silent loss, and complete raw-to-action traceability
* Explicit finality, correction, and manual recovery semantics
* One nonce authority per signing address for any onchain write

## Observability

Deployments emit OpenTelemetry-compatible metrics, logs, and traces, and can forward to your existing observability stack. Incident evidence and replay controls are part of the control plane, not an add-on.
