Security and compliance

This page explains how Clouve protects your data, isolates your deployments, and manages security across the platform.

Isolation

Every organization's deployments run in completely isolated environments. Your application's database, files, and configuration exist only in your organization's namespace; other organizations cannot see, access, or affect them. Your application containers run separately from any other organization's containers, even on shared infrastructure, and your credentials and passwords are stored in isolated Kubernetes Secrets that only your namespace can access.

This is different from shared SaaS applications, where all customers' data lives in the same database. On Clouve, your deployment is a private instance of the application, not a tenant in a shared system.

Encryption

Data in transit

All traffic to and from your applications is encrypted with TLS (HTTPS). Clouve provisions a TLS certificate for every deployment via Google Public CA, a trusted certificate authority, and renews it automatically before it expires, so you never manage certificates yourself. HTTPS is enforced: HTTP connections are redirected to HTTPS. Your application URL always starts with https://, and there is no unencrypted HTTP access to production deployments.

Data at rest

Application data on persistent volumes is encrypted at rest with the cloud provider's default encryption (Google Cloud, AWS, or Azure managed encryption). This covers database files, application uploads and attachments, and configuration files.

Credential storage

Passwords and secrets you provide at deployment time are stored in Kubernetes Secrets, which are:

  • Base64-encoded in Kubernetes storage
  • Access-controlled: only your application's containers can read them
  • Not exposed in platform logs or dashboards
  • Not visible to Clouve platform administrators

Important: The platform stores your initial deployment passwords. Changing your application password inside the application (after first login) changes only the application's internal authentication, not the platform's stored copy. For ongoing security, change your application passwords through the application itself after initial setup.

Network security

Public and private containers

Each application is designed with a network boundary in mind. Public containers (typically the web frontend) are reachable from the internet over HTTPS. Private containers (databases, caches, internal services) are reachable only from other containers within the same deployment, never from the internet.

In a WordPress deployment, for example, the WordPress application is public and accessible from your browser, while the MariaDB database is private and only the WordPress container can connect to it.

This limits the attack surface: even if an application vulnerability were exploited, the database remains unreachable from outside.

Namespace isolation

Kubernetes network policies prevent cross-namespace communication. Your deployment cannot communicate with another organization's deployment, even within the same cluster infrastructure.

Authentication

Platform login

Users sign in to the Clouve dashboard with an email address and password, or with their Google account (Google OAuth 2.0). Removing a user from the Clouve organization revokes their access. For users who sign in with Google, two-factor authentication (2FA) is managed through your Google Workspace (or personal Google) settings.

Application login

Logging in to deployed applications (WordPress, Moodle, etc.) is managed entirely by the application itself. Clouve does not control or monitor application-level authentication.

For application accounts:

  • Use strong, unique passwords for admin accounts
  • Enable any built-in 2FA features the application provides
  • Audit user accounts in the application regularly and remove access for departed team members
  • Use the application's role system to limit what each user can do

Updates and security patches

The open-source applications in the Clouve marketplace receive regular security updates from their developer communities. When a security patch is released, the Clouve developer who maintains the marketplace packaging updates the application, the update appears in your dashboard as "Update Available", and you apply it at a time that suits your organization.

Apply security updates promptly: unpatched vulnerabilities in application software are a significant risk. The platform does not apply updates automatically; you control when they happen. For critical security patches, your Clouve administrator may notify you and recommend urgent action.

Data residency

By default, your deployment runs in the cloud region configured for your organization's workspace. If you have data residency requirements, for example that data must stay in the EU or within a specific country, discuss them with your Clouve administrator before deploying.

Clouve supports Google Cloud Platform (GCP), Amazon Web Services (AWS), and Microsoft Azure, each with multiple regions globally.

Backup and recovery

Platform-level protection

Clouve's persistent volumes live on cloud-provider managed storage (GCP Persistent Disk, AWS EBS, Azure Disk). This storage is redundant across multiple physical disks, designed for 99.999%+ durability (losing data to hardware failure is highly unlikely), and survives node failures and scheduled maintenance automatically.

Application-level backups

On a paid plan, the deployment's Backups tab lets you schedule backups (daily, weekly or monthly) and take one on demand. Free trials don't include backups. Backups are not switched on automatically, so turn on a schedule for business-critical applications; you can also use the application's built-in backup features (Moodle, Odoo, and WordPress all have backup tools).

See the data export section in Managing deployments for application-level backup instructions.

Disaster recovery

If a significant platform issue occurs, the Clouve team has runbooks and procedures for restoring service. Your data lives in persistent volumes, separate from the compute infrastructure, and is preserved during cluster incidents.

Compliance considerations

Data processing

Your organization's data is processed in the cloud region you select. Review your cloud provider's compliance certifications (SOC 2, ISO 27001, GDPR, HIPAA eligibility, etc.) for the region you deploy to.

GDPR

If your organization serves EU users and processes personal data:

  • Make sure your selected cloud region complies with your GDPR obligations
  • The applications themselves (WordPress, Moodle, etc.) must be configured to comply with GDPR; check each application's documentation for GDPR-relevant settings
  • Data deletion requests must be fulfilled within the application

Healthcare (HIPAA)

If you handle Protected Health Information (PHI), consult your compliance officer before deploying healthcare applications on Clouve. HIPAA compliance requires Business Associate Agreements (BAAs) with cloud providers; contact your Clouve administrator.

Reporting security issues

If you discover a security vulnerability in the Clouve platform or in a marketplace application, do not disclose it publicly. Report it privately to the Clouve security team through your administrator or support channel. For vulnerabilities in the underlying open-source applications (WordPress, Moodle, etc.), report directly to the respective project's security team.

Next steps