Frequently asked questions.

No. Your connected storage provider holds the stored data. RED (RheaData) is the environment for protected documents, permissions, sharing, collection, supported movement and recorded activity. Rhea's broader direction is a reusable authority and operations layer across supported systems.

RED's current public storage path is customer-owned AWS S3. Current document workflows include protection, organization, sharing, file requests, supported S3 movement and recorded activity. The Product Status page distinguishes these from controlled pilots, development work and planned expansion.

RED-protected file content is stored as ciphertext in connected customer-owned storage. Rhea processes operational metadata and wrapped key material, and current connection modes can use provider credentials processed by its backend. Authorized devices handle readable content. The metadata and credentials page explains these boundaries.

Only encrypted protected-file content and the object metadata needed to store it, such as object keys, sizes and access times. The storage provider does not receive plaintext or encryption keys.

RED and Rhea may process the operational metadata required to provide authorization, organization administration, metering, security and audit functions — for example organization structure, roles, sessions, document identifiers, storage references, usage records, and audit events. This operational metadata is distinct from protected file content and does not include the plaintext of anything stored.

Bring Your Own Storage (BYOS) means encrypted objects are written to a storage bucket the organization owns and controls rather than to a Rhea-hosted store. RED encrypts each object client-side with AES-256-GCM, then uploads the ciphertext. AWS S3 is generally available today. MinIO and S3-compatible storage, Microsoft Azure Blob Storage and Google Cloud Storage are in controlled pilot. Cloudflare R2, Oracle Object Storage and private or on-premises deployments are planned.

Database connectivity is planned, starting with PostgreSQL. The direction is scoped database operations enforced in the customer's environment. This is not a claim that RED currently supports production database queries or arbitrary querying over encrypted data.

Rhea Key authenticates the user and signs approvals in supported Rhea workflows. RED's organizational and resource permissions still determine what is allowed. Possessing or connecting a key does not grant universal access to an organization's data.

Because private authentication material stays on the user's device and Rhea does not operate a key-recovery service, losing the device without a working recovery path can make data whose access depended only on that device's key unrecoverable through it. A lost or compromised device should be reset from another trusted device or reported so its authority can be invalidated for future authorizations.

Rhea ID is in development for verified identity attributes that can inform authorization decisions. It is separate from Rhea Key's cryptographic authentication. It is not a prerequisite for RED's current supported workflows.

No. Organizations operating under GDPR, NIS2, DORA, EHDS or sector-specific requirements may evaluate RED as one technical and organizational control within a broader compliance programme. RED does not by itself make an organization compliant, and legal obligations depend on the organization's deployment, policies, processes, contracts and applicable law.

No. RED uses a Bring Your Own Storage (BYOS) model. Your organization connects RED to storage under its own control. Rhea does not provide, host, or operate customer storage.