Skip to main content

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/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/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

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
  • No Data Access - Qovery never has access to your application data

Encryption

Qovery implements comprehensive encryption strategies to protect your data throughout its lifecycle, from transmission to storage.
Qovery ensures all communications are encrypted using industry-standard protocols.

Qovery Services

  • Qovery CLI - All API communications encrypted with TLS
  • Management Console - HTTPS-only access
  • Documentation - Served over HTTPS
  • Landing Page - Encrypted web traffic
  • Back Office - Secure administrative access

Customer Application Encryption

Your applications deployed on Qovery benefit from automatic HTTPS protection:
  • Automatic SSL/TLS Certificates - Powered by Let’s Encrypt
  • Free certificates - No additional cost
  • Auto-renewal - Certificates automatically renewed before expiration
  • Custom TLS Certificates - Available for enterprise users

Internal Network Encryption

Data in transit on Qovery-controlled networks uses:
  • End-to-end encryption - Data encrypted throughout the entire transmission
  • Private networking rules - Traffic isolated within your VPC
  • TLS 1.2+ - Modern encryption protocols only
  • Perfect Forward Secrecy - Each session uses unique encryption keys
Internal traffic never leaves your cloud provider’s network, adding an extra layer of security through network isolation.
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

ComponentEncryption MethodKey Management
Application VolumesAES-256Cloud provider KMS
Database StorageAES-256Cloud provider KMS
Backups/SnapshotsAES-256Cloud provider KMS
S3/Object StorageAES-256Cloud provider KMS
Container RegistryAES-256Cloud provider KMS
LogsAES-256Cloud provider KMS
AES-256 is approved for top-secret information by the NSA and is the industry standard for data encryption.
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
  • Database Passwords
  • TLS/SSL Private Keys
  • OAuth Client Secrets
  • Encryption Keys
  • Service Account Credentials

Secret Encryption Details

Encryption Method:
  • Algorithm: Salted AES-256
  • Salt: Unique per secret (prevents rainbow table attacks)
  • Key derivation: PBKDF2 or similar
  • Storage: Encrypted in Qovery database
Access Control:
  • Secrets encrypted at rest in Qovery’s infrastructure
  • Decrypted only when deployed to your environment
  • Transmitted over encrypted channels only
  • Never logged or exposed in plain text
Once a secret is created, it cannot be retrieved in plain text through the Qovery Console. You can only update or delete it.

Secret Injection

Secrets are securely injected into your applications:
  1. At Build Time (if needed)
    • Decrypted on secure build node
    • Available as environment variables during build
    • Not stored in container image
  2. At Runtime
    • Decrypted and injected as environment variables
    • Available only to the specific container
    • Stored in container memory only (not on disk)
Encryption keys are managed by your cloud provider’s Key Management Service (KMS):
  • AWS - AWS Key Management Service (KMS)
  • GCP - Cloud Key Management Service
  • Azure - Azure Key Vault
  • Scaleway - Scaleway KMS
Key Rotation:
  • Keys are automatically rotated according to cloud provider policies
  • No manual intervention required
  • Zero downtime during key rotation
Customer-Managed Keys:
  • Enterprise customers can use customer-managed keys (CMK)
  • Bring your own keys (BYOK) supported
  • Contact Qovery support to configure
Different cloud providers offer varying levels of encryption capabilities:
  • AWS
  • GCP
  • Azure
  • Scaleway
Encryption Features:
  • EBS volumes encrypted with AWS KMS
  • RDS encryption at rest with KMS
  • S3 server-side encryption (SSE-S3 or SSE-KMS)
  • Certificate Manager for TLS certificates
  • Secrets Manager for secret storage
Key Management:
  • AWS KMS for key management
  • Customer-managed keys (CMK) available
  • Automatic key rotation
  • CloudTrail logging of key usage

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.
Container applications maintain backup 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:
  1. Every successful build creates a new container image
  2. Image is tagged with a unique identifier (commit SHA, build ID)
  3. Image is pushed to your container registry
  4. 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.
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
  • Encrypted backups - All backups encrypted at rest
  • Geographic redundancy - Backups stored across multiple availability zones

Backup Retention

Default retention periods vary by cloud provider:
ProviderAutomated BackupsManual SnapshotsPoint-in-Time
AWS RDS7-35 daysIndefiniteLast 5 minutes
GCP Cloud SQL7-365 daysIndefiniteLast second
Azure Database7-35 daysIndefiniteLast 5 minutes
Scaleway7 daysIndefiniteNot available
The Qovery configuration file resides in your Git repository with full version control.Restoration Methods:
  • Via Qovery Console
  • Via Git Rollback
  • Via CLI
  1. Go to your application in the Qovery Console
  2. Navigate to DeploymentsHistory
  3. Select the version you want to restore
  4. Click Redeploy this version
This redeploys the exact container image from the previous build - no rebuild required!
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 restoration is managed by your cloud provider and creates a new database instance.
1

Access Cloud Provider Console

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

Navigate to Database Service

Find your managed database service:
  • AWS: RDS or DocumentDB
  • GCP: Cloud SQL or Firestore
  • Azure: Azure Database
  • Scaleway: Managed Databases
3

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)
4

Create New Database Instance

Cloud providers create a new database instance from the backup:
  1. Configure instance settings
  2. Choose VPC and security groups
  3. Wait for restoration to complete (5-30 minutes)
5

Update Application Configuration

Update your application to point to the new database:
  1. In Qovery Console, go to your application
  2. Update environment variables with new database endpoint
  3. Redeploy your application
6

Verify and Cleanup

  1. Verify data integrity in restored database
  2. Test application connectivity
  3. 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

Recovery Time Objectives (RTO)

Typical recovery times for Qovery-managed services:
ComponentRTONotes
Application< 5 minutesRedeploy previous container image
Database (Snapshot)15-30 minutesCreate new instance from snapshot
Database (PITR)30-60 minutesRestore to specific point in time
Configuration< 5 minutesRoll back Git configuration
Full Cluster2-4 hoursRebuild 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


Security Best Practices

Never hardcode secrets in code. Use Qovery secret manager or external providers like Doppler, AWS Secrets Manager, or HashiCorp Vault.
Always use HTTPS for public applications. Qovery provides automatic SSL certificates via Let’s Encrypt.
Grant minimum required permissions to users and service accounts using RBAC.
Require MFA for all team members to protect against compromised credentials.
Regularly test restore procedures to ensure backups work when needed.
Set up alerts for suspicious activities and review audit logs regularly.

Access Control

Authentication:
  • Email/password with 2FA
  • SSO via SAML 2.0
  • OAuth 2.0 (Google, GitHub, GitLab)
Authorization:
  • Role-based access control (RBAC)
  • Predefined roles: Owner, Admin, Developer, Viewer
  • 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, retained for 30+ days, and can be exported to SIEM systems. View audit logs documentation →

Security Incident Response

For security issues or vulnerabilities:

Learn More