Security Overview

Your Data Stays on Your Infrastructure

Qovery is designed so your data always stays within your own infrastructure. This core design principle ensures maximum security and control.

Qovery operates as a control plane that only transfers metadata using gRPC or TLS. All your application data, databases, and workloads remain exclusively within your cloud infrastructure.

Security Architecture

Your Infrastructure Not Exposed

Your infrastructure is never exposed. Qovery control plane only receives metadata via encrypted gRPC or TLS.

Data On Your Infrastructure

All data stays within your cloud account. Qovery never stores or processes your application data.

Processes On Your Infrastructure

All application processes run on your Kubernetes clusters. Qovery only manages orchestration.

Pen-Tested Regularly

Security is tested regularly by independent security agencies.

How It Works

Managed Clusters
BYOK Clusters

For Managed Clusters, Qovery manages the engine infrastructure:Key Principles:

Control Plane Separation - Qovery’s control plane is separate from your data plane
Metadata Only - Only configuration and status metadata transits to Qovery
Encrypted Communication - All communication uses gRPC over TLS
Your Cloud Account - All resources provisioned in your cloud account

Encryption

Qovery implements comprehensive encryption strategies to protect your data throughout its lifecycle, from transmission to storage.

Data in Transit

Qovery ensures all communications are encrypted using industry-standard protocols.

Qovery Services

Qovery Client to Backend - HTTPS and WebSocket Secure enforced.
Qovery Backend to Backend - HTTPS or gRPC with TLS
Documentation and public website - Served over HTTPS
TLS 1.2 - On all endpoints, all rated A+ by Qualys’ SSL Labs tools

Customer Application Encryption

Your applications deployed on Qovery benefit from automatic HTTPS protection:

Automatic SSL/TLS Certificates - Powered by Let’s Encrypt
Free, auto-renewed certificates - No additional cost, automatically renewed before expiration
Custom TLS Certificates - Available for enterprise users
Secure by default - All your public endpoints are covered by default

Internal traffic never leaves your cloud provider’s network, adding an extra layer of security through network isolation.

Data at Rest

Application data receives protection through encrypted storage mechanisms across all supported cloud providers.

Storage Encryption

Qovery predominantly utilizes AES-256 block cipher encryption for data at rest:

Volume Encryption - All persistent volumes encrypted
Database Encryption - Managed database encryption enabled by default
Snapshot Encryption - Backups and snapshots encrypted
Log Storage - Application and infrastructure logs encrypted

Encryption Coverage

Component	Encryption Method	Key Management
Application Volumes	AES-256	Cloud provider KMS
Database Storage	AES-256	Cloud provider KMS
Backups/Snapshots	AES-256	Cloud provider KMS
S3/Object Storage	AES-256	Cloud provider KMS
Container Registry	AES-256	Cloud provider KMS
Logs	AES-256	Cloud provider KMS

AES-256 is the industry standard for data encryption, recommended by NIST, ANSSI, and BSI.

Secrets Management

Sensitive information receives enhanced protection using salted AES-256 encryption methods.

What Qualifies as a Secret?

Environment Variables marked as “Secret”
API Keys and Tokens incl. GitHub access tokens.
Cloud Service Provider credentials
TLS/SSL Private Keys
OAuth Client Secrets
Encryption Keys
Service Account Credentials

Secret Encryption Details

Encryption Method:

Algorithm: AES-256
Key derivation: PBKDF2
Salt: Unique per customer
Storage: Encrypted in Qovery database

Access Control:

Secrets encrypted at rest in Qovery’s infrastructure
Decrypted only when required
Transmitted over encrypted channels only

Secret Injection

Secrets are securely injected into your applications:

At Build Time (if needed)
- Only the secrets specified
- Used by disposable, transient build node
- Available as environment variables during build
- Not stored in container image
At Runtime
- Decrypted and injected as environment variables
- Available only to the specific container
- Stored in container memory only (not on disk)

Encryption by Cloud Provider

Different cloud providers offer varying levels of encryption capabilities:

AWS
GCP
Azure

Encryption Features:

EBS volumes are encrypted with AWS KMS
RDS databases and snapshots are encrypted at rest with KMS
S3 bucket for VPC flow logs use server-side encryption (SSE-S3 or SSE-KMS)

Backup and Restore

Backups and restore are frequently a nightmare to setup, especially for databases. Qovery helps you get this part always automatically managed by the Cloud provider.

Application Rollback

Container applications maintain rollback capabilities through container image retention:

All successfully built container images are retained
Images are stored in your container registry
Previous versions remain available for rollback
No data loss when rolling back to earlier versions

How it works:

Every successful build creates a new container image
Image is tagged with a unique identifier (commit SHA, build ID)
Image is pushed to your container registry
Previous images remain available for rollback

Container images act as snapshots of your application at specific points in time. You can roll back to any previous build instantly.

Database Backups

Managed databases have automatic daily backups managed by your cloud provider:

Automated daily backups - No manual configuration required
Point-in-time recovery - Restore to specific timestamps, when available
Encrypted backups - All backups encrypted at rest

Backup Retention

Default retention periods vary by cloud provider:

Provider	Automated Backups	Manual Snapshots	Point-in-Time
AWS RDS	7-35 days	Indefinite	Last 5 minutes
GCP Cloud SQL	7-365 days	Indefinite	Last second
Azure Database	7-35 days	Indefinite	Last 5 minutes
Scaleway	7 days	Indefinite	Not available

PostgreSQL

Automated daily backups with point-in-time recovery

MySQL

Daily snapshots with configurable retention

MongoDB

Continuous backups with point-in-time restore

Redis

Daily snapshots of persistent data

This applies to cloud-provider-managed databases. Container-based databases are not recommended for production usage, and provide no automatic backup feature.

Application Restore

The Qovery configuration file resides in your Git repository with full version control.Restoration Methods:

Via Qovery Console
Via Git Rollback
Via CLI

Go to your environment in the Qovery Console
Find your application in the list of Services
Select the version you want to restore using the Deploy another version button
Click Deploy

This redeploys the exact container image from the previous build - no rebuild required!

Identify the commit you want to roll back to:
```
git log --oneline
```

Revert to that commit:

# Option 1: Revert specific commit (creates new commit)
git revert <commit-hash>

# Option 2: Reset to specific commit (rewrites history)
git reset --hard <commit-hash>
git push --force

Qovery automatically detects the change and redeploys

When you rollback a commit containing a Qovery configuration change, ensure there are no other changes to avoid unwanted behavior.

Use the Qovery CLI to redeploy a specific version:

# Redeploy specific version
qovery application deploy -n <app-name> -c <commit-id>

Best Practices:

Test rollbacks in staging before production
Review configuration changes before rolling back
Communicate with your team before rollback
Monitor after rollback to ensure stability

Database Restore

Database restoration is managed by your cloud provider and creates a new database instance.

Access Cloud Provider Console

Log into your cloud provider console (AWS, GCP, Azure, or Scaleway).

Navigate to Database Service

Find your managed database service:

AWS: RDS or DocumentDB
GCP: Cloud SQL or Firestore
Azure: Azure Database
Scaleway: Managed Databases

Select Restore Point

Choose your restoration method:Point-in-Time Recovery (PITR):

Restore to any time within retention period
Most accurate recovery method
No data loss up to the specific second

Snapshot Restore:

Restore from daily automated snapshots
Faster than PITR
Some data loss possible (data since last snapshot)

Create New Database Instance

Cloud providers create a new database instance from the backup:

Configure instance settings
Choose VPC and security groups
Wait for restoration to complete (5-30 minutes)

Update Application Configuration

Update your application to point to the new database:

In Qovery Console, go to your application
Update environment variables with new database endpoint
Redeploy your application

Verify and Cleanup

Verify data integrity in restored database
Test application connectivity
Delete old database instance if no longer needed

Database restores create a new instance. Your application will need to be reconfigured to use the restored database endpoint.

Cloud Provider Documentation

AWS RDS Restore

Amazon RDS backup and restore guide

GCP Cloud SQL Restore

Google Cloud SQL restore documentation

Azure Database Restore

Azure Database backup and restore

Scaleway Kapsule

Scaleway managed database backups

Disaster Recovery Planning

Recovery Time Objectives (RTO)

Typical recovery times for Qovery-managed services:

Component	RTO	Notes
Application	< 5 minutes	Redeploy previous container image
Database (Snapshot)	15-30 minutes	Create new instance from snapshot
Database (PITR)	30-60 minutes	Restore to specific point in time
Configuration	< 5 minutes	Roll back Git configuration
Full Cluster	2-4 hours	Rebuild cluster from scratch

Best Practices

Test restore procedures regularly - Schedule quarterly restore drills
Implement multi-region redundancy - Deploy critical applications across regions
Monitor backup health - Set up alerts for failed backups
Maintain documentation - Keep runbooks updated with restore procedures
Consider compliance - Ensure backup retention meets regulatory requirements

Compliance Certifications

Qovery adheres to applicable cybersecurity regulations and holds certifications for relevant security frameworks, including:

SOC 2 Type II

Security controls audited annually

GDPR

European data protection laws

HIPAA

US Healthcare data protection laws

DORA

Digital resilience compliance

Security Best Practices

Use secret management

Never hardcode secrets in code. Use Qovery secret manager or external providers like Doppler, AWS Secrets Manager, or HashiCorp Vault.

Enable HTTPS everywhere

Always use HTTPS for public applications. Qovery provides automatic SSL certificates via Let’s Encrypt.

Implement least privilege

Grant minimum required permissions to users and service accounts using RBAC.

Enable multi-factor authentication

Require MFA for all team members to protect against compromised credentials.

Test your backups regularly

Regularly test restore procedures to ensure backups work when needed.

Monitor security events

Set up alerts for suspicious activities and review audit logs regularly.

Access Control

Authentication: Access to the Qovery service requires the use of an external identity provider, and relies on an industry-standard solution to offer state-of-the-art authentication security.

SSO via SAML 2.0 or OIDC
OAuth 2.0 “Social Login” providers: Google, GitHub, GitLab, BitBucket, Microsoft

Authorization:

Role-based access control (RBAC) system
Predefined roles: Owner, Admin, Developer, Viewer
Custom roles to manage scope of access (clusters, environments)
Organization, project, and environment-level permissions

Configure organization access →

Audit Logging

All actions in Qovery are logged for security and compliance:

User authentication and authorization
Resource creation, modification, deletion
Configuration changes
Deployment activities
API access

Audit logs are immutable, and can be exported as JSON files. Logs retention duration depends on your plan. Custom settings possible. View audit logs documentation →

Security Incident Response

For security issues or vulnerabilities:

Email: [email protected]

Learn More

Audit Logs

Track all changes and actions in your organization

SOC 2 Compliance

SOC 2 Type II certification details

GDPR Compliance

Data protection and privacy

Database Configuration

Configure database settings and backups

Get Started

Platform Capabilities

How-to Guides

Tutorials

Troubleshooting

Useful Resources

​Your Data Stays on Your Infrastructure

​Security Architecture

Your Infrastructure Not Exposed

Data On Your Infrastructure

Processes On Your Infrastructure

Pen-Tested Regularly

​How It Works

​Encryption

​Qovery Services

​Customer Application Encryption

​Storage Encryption

​Encryption Coverage

​What Qualifies as a Secret?

​Secret Encryption Details

​Secret Injection

​Backup and Restore

​Backup Retention

PostgreSQL

MySQL

MongoDB

Redis

​Cloud Provider Documentation

AWS RDS Restore

GCP Cloud SQL Restore

Azure Database Restore

Scaleway Kapsule

​Recovery Time Objectives (RTO)

​Best Practices

​Compliance Certifications

SOC 2 Type II

GDPR

HIPAA

DORA

​Security Best Practices

​Access Control

​Audit Logging

​Security Incident Response

​Learn More

Audit Logs

SOC 2 Compliance

GDPR Compliance

Database Configuration

Your Data Stays on Your Infrastructure

Security Architecture

How It Works

Encryption

Qovery Services

Customer Application Encryption

Storage Encryption

Encryption Coverage

What Qualifies as a Secret?

Secret Encryption Details

Secret Injection

Backup and Restore

Backup Retention

Cloud Provider Documentation

Recovery Time Objectives (RTO)

Best Practices

Compliance Certifications

Security Best Practices

Access Control

Audit Logging

Security Incident Response

Learn More