Security and data

The answers your security review asks for.

Rytiv is run by a German company. Below are the questions a security or procurement review asks, answered from the code and from what runs on our production hosts.

EUApps, databases and files are stored and run only in the EU.

VMOwn kernel per machine.

AES-256-GCMSecrets in the platform database, never returned.

2FAEvery account. Passkeys, no passwords.

Where your workloads run

Your apps, databases and files are stored and run only in the EU.

Who operates the service?: A limited company (GmbH) registered in Germany, at Amtsgericht Oldenburg. The imprint names it in full.
Where are apps, databases and files stored and run?: Only in the EU. Every app, computer, sandbox, database and bucket of a workspace runs in its EU region. Backup copies of the platform database and the storage layer are kept in another EU country, encrypted before they leave.
Who else receives data?: The privacy page names every recipient, with what each one does.
Can a machine move to another region?: No. A machine is placed in its region when it is created and stays there for its lifetime: a move to another host, a host failure and a deploy that replaces machines all stay inside the region.
Does Rytiv process card numbers?: No. Payment pages are served by the payment provider, and card numbers never reach Rytiv.
Does a third-party content delivery network sit in the path?: No. Static sites are served from the region's own edge.

In the docs: Regions →

Isolation and network

Every machine is its own virtual machine with its own kernel.

How are tenants isolated?: Every machine, including an app's, a computer's, a sandbox's and a database's compute, runs in its own virtual machine with its own kernel, not a container on a shared kernel. A key acts as one organization and sees nothing of another; a name of another organization answers like a name that does not exist.
What can reach a database?: The apps attached to it. A database's internal name resolves only inside those apps, and it accepts TLS connections only. ry proxy opens a tunnel for a person with a key.
Can apps reach each other?: Machines of one app reach each other over the private network. Another app is reachable only through an explicit link.
Can outbound traffic be restricted?: A sandbox is created with an outbound policy: everything, nothing (not even DNS), or an allowlist of up to 100 domains and 10 IPv4 ranges on ports 80 and 443. The policy is fixed for the sandbox's lifetime.
Can a preview be closed to the public?: Yes. An app can be protected by a password or by share links you hand out, each with a label and an optional expiry, and revoked one by one.

In the docs: Security and data →

Secrets

Encrypted in the platform database, handed to the machines that start, never returned by the API.

How are secrets stored?: In the platform database, encrypted with AES-256-GCM under a key the platform holds outside the database. They are decrypted only to hand them to a machine that starts.
Can secrets be read back?: No. The API lists names, when they changed, whether Rytiv manages them and whether a build sees them. It never returns a value.
Do builds see runtime secrets?: Only secrets marked for the 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.

In the docs: Security and data →

Transport security

TLS on every app address and every database connection.

Is traffic to apps encrypted?: Yes. https://<app>.rytiv.app is covered by the platform's certificate from the first deploy, and port 80 redirects to HTTPS.
What about custom domains?: A custom domain gets its own certificate over ACME once ownership is proven, renewed when fewer than 30 days remain.
Are database connections encrypted?: A Postgres database accepts TLS connections only. The connection URL uses sslmode=verify-full against a certificate authority every machine carries at /etc/rytiv/ca/postgres.crt.

In the docs: Custom domains and TLS →

API keys and access control

Keys are hashed, shown once, narrowed by scope, class, app list and expiry.

How are API keys stored?: As a hash. A key is shown exactly once, when it is created; afterwards only its prefix is visible.
Can a key be limited?: Yes. Scopes narrow a key to reading, deploying all apps or one app, or sending mail. An expiry ends it after 60 seconds to 365 days, and a key cannot create a key that outlives it. Revoking a key rejects requests already using it right away.
How are coding agents limited?: An agent key carries a class the platform enforces on every request. sandbox and twin may do what a key of the organization may do, except touch credentials; production may only read, and files and query results need an explicit flag. An app list limits the key to 1 to 50 named apps.
Can a narrowed key escalate?: No. A key with scopes or an agent class can never mint, reveal or revoke a credential, administer the organization or act for another organization.
Who can change billing?: Only an admin of the team in the console. The billing routes refuse a plain API key.

In the docs: Authentication →

Accounts and sign-in

Passkeys, no passwords for new accounts, a second factor for every account.

How do people sign in?: With a passkey, a one-time code by e-mail, or GitHub where it is switched on. New accounts have no password.
Is multi-factor authentication enforced?: Every account enrols a second factor.
How does the CLI sign in?: ry login shows a device code you confirm in the console. The key it receives is a key of your team like any other and can be revoked under API keys.
How do hosted tools connect?: Over OAuth 2.1. Every client is a public client bound to PKCE with S256; you approve it once in the console. Access tokens live one hour, refresh tokens 30 days and rotate on every use.

In the docs: Security and data →

Audit and logging

Agent changes are audited before they run. Shell and desktop access is audited.

Are agent actions logged?: Every refusal and every allowed request beyond a plain read is written to an audit before it runs, with the route, the verdict and the key. A change that cannot be recorded does not run. A key narrowed with scopes cannot read the audit.
Is access into machines logged?: A shell, a tunnel or a file transfer into a machine needs a key with full access and is audited. On a computer, the audit shows who got a view or control link and how control ended.
How long are logs kept?: Build logs 30 days. Agent, shell and computer audits 90 days.

In the docs: Agents and tokens →

Backups and durability

Every Postgres commit is on more than one storage node. Volumes are snapshotted on a cadence you set.

How are volumes backed up?: A volume is snapshotted to object storage on a cadence you set, daily by default.
Point-in-time recovery for databases?: Every database keeps a history of its write-ahead log, 7 days by default, 1 to 30 days per database. You can fork from any moment in that window or restore in place; the state before a restore is kept as a database of its own until the window ends.
High availability?: Every commit to a database is stored on more than one storage node, and a failed compute starts again on another host. An app runs up to 20 machines.
Can a bad deploy be undone?: Every deploy is a release and can be rolled back without a rebuild. For five minutes after a deploy to machines, Rytiv compares the error rate with the rate before and rolls back on its own if it is clearly worse. Databases are never rolled back automatically.
What does deleting do?: Deleting an app, a database, a volume or a bucket is final, and the CLI asks you to type the name first.

In the docs: Postgres →

Reporting a problem

One address for security reports, one for abuse.

How do we report a vulnerability?: Write to security@rytiv.com. A person reads it, in German or English. The same address is published in /.well-known/security.txt.
How do we report abuse or illegal content?: Write to abuse@rytiv.com. The page Report abuse says what to include and what happens then.

In the docs: Error catalog →

Documents for your review

Lists and contracts your legal team will ask for.

Terms of service: Terms
Acceptable use: Acceptable Use Policy
Data processing agreement (DPA, AVV under Art. 28 GDPR): DPA, with its annexes and sub-processors
Who receives data: The list on the privacy page
Privacy notice: Privacy
Sovereignty: What we run and at which layer we start
Limits and quotas: Every bound the platform enforces

The answers your security review asks for.

Bring it to your review.