# Security and data

> Where your data lives, how secrets are kept, what a key can reach, how machines are isolated and what TLS covers.

## Data residency

Your workloads and data stay in the region of your workspace, in the EU at launch; see [Regions](https://docs.rytiv.com/concepts/regions.md). Account and billing data stay in the EU whatever the region. Payment pages are served by the payment provider; no card data crosses the Rytiv API.

## Secrets

- Secrets are encrypted at rest with AES-256-GCM under a key the platform holds outside the database, and decrypted only when they are handed to a machine that starts.
- The API never returns a value: `GET /v1/apps/:name/secrets` lists names, when they changed, whether Rytiv manages them, and whether a build sees them.
- **Runtime and build are separate.** Every secret reaches the running app. A build sees only the secrets marked for it (`build: true`; `ry secrets set --build`). A new secret is marked by default only when its name carries a public prefix such as `NEXT_PUBLIC_` or `VITE_`. Secrets the platform creates (`DATABASE_URL`, `S3_*`, `RYTIV_CRON_SECRET`) are runtime only.
- Secrets reach a machine when it starts. A running machine keeps the environment it started with; a new deploy, or a stop and start, picks up the change.
- Managed secrets (the connection URL of an attached database, the key of an attached bucket) follow their attachment and cannot be changed or removed by hand.

## Keys and what they reach

- A key acts as one organization and sees nothing of another; a name of another organization answers like a name that does not exist.
- Keys are stored as a hash; the value is shown once, when created.
- Scopes narrow a key to reading, deploying one app, or sending mail; agent tokens carry a class and an app list the platform enforces on every request. See [Agents and tokens](https://docs.rytiv.com/guides/agents-and-tokens.md).
- A key with scopes or an agent token can never mint, reveal or revoke a credential.
- A shell, a tunnel or a file transfer into a machine needs a key with full access and is audited.

## Machines

- Every app, computer, sandbox and database runs in its own virtual machine with its own kernel, not a container on a shared kernel.
- Machines of one app reach each other over the private network; another app only through an explicit link (`ry link`). A database's internal name resolves only inside the apps attached to it.
- A sandbox can be created with an outbound policy: everything, nothing, or an allowlist of domains and address ranges.

## TLS

- `https://<app>.rytiv.app` is covered by the platform's certificate from the first deploy; port 80 redirects to HTTPS.
- A custom domain gets its own certificate over ACME once ownership is proven, renewed when fewer than 30 days remain. See [Custom domains and TLS](https://docs.rytiv.com/guides/custom-domains.md).
- A Postgres database accepts TLS connections only. The connection URL uses `sslmode=verify-full` against a certificate authority that every machine carries at `/etc/rytiv/ca/postgres.crt`.

## Signing in

The console signs in with a passkey, a one-time code by e-mail, or GitHub where it is switched on; new accounts have no password, and every account enrols a second factor. `ry login` uses a device code you confirm in the console at `https://console.rytiv.com/device`; the key it receives is a key of your team like any other and can be revoked under **Team, Tokens & keys**.

## Durability

- A volume is copied to object storage on a schedule and before its machine sleeps; a database keeps a continuous archive of its write-ahead log (7 days) on top of that, which forks and point-in-time restores read.
- An agent machine with durable checkpoints survives a host failure with its last checkpoint; a computer comes back with the last copy of its home.
- Deleting an app, a database, a volume or a bucket cannot be undone. The CLI asks you to type the name; automation passes `--yes`.