Security and data

Data residency

Your workloads and data stay in the region of your workspace, in the EU at launch; see Regions. 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.
• 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.
• 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.