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.Data in Transit
Data in Transit
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
Data at Rest
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 approved for top-secret information by the NSA and is the industry standard for data encryption.
Secrets Management
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
- 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
- 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
Secret Injection
Secrets are securely injected into your applications:-
At Build Time (if needed)
- Decrypted on secure 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)
Key Management
Key Management
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
- Keys are automatically rotated according to cloud provider policies
- No manual intervention required
- Zero downtime during key rotation
- Enterprise customers can use customer-managed keys (CMK)
- Bring your own keys (BYOK) supported
- Contact Qovery support to configure
Encryption by Cloud Provider
Encryption by Cloud Provider
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
- 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.Application Backups
Application Backups
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
- 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
Database Backups
Database Backups
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:| 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 |
Application Restore
Application Restore
The Qovery configuration file resides in your Git repository with full version control.Restoration Methods:Best Practices:
- Via Qovery Console
- Via Git Rollback
- Via CLI
- Go to your application in the Qovery Console
- Navigate to Deployments → History
- Select the version you want to restore
- Click Redeploy this version
This redeploys the exact container image from the previous build - no rebuild required!
- 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 Restore
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
- 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:
- Configure instance settings
- Choose VPC and security groups
- Wait for restoration to complete (5-30 minutes)
5
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
6
Verify and Cleanup
- Verify data integrity in restored database
- Test application connectivity
- Delete old database instance if no longer needed
Cloud Provider Documentation
Disaster Recovery Planning
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
SOC 2 Type II
Security controls audited annually
GDPR
European data protection compliance
HIPAA
Healthcare data protection
HDS
French health data hosting
DORA
Digital resilience compliance
Security Best Practices
Use secret management
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
Enable HTTPS everywhere
Always use HTTPS for public applications. Qovery provides automatic SSL certificates via Let’s Encrypt.
Implement least privilege
Implement least privilege
Grant minimum required permissions to users and service accounts using RBAC.
Enable multi-factor authentication
Enable multi-factor authentication
Require MFA for all team members to protect against compromised credentials.
Test your backups regularly
Test your backups regularly
Regularly test restore procedures to ensure backups work when needed.
Monitor security events
Monitor security events
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)
- Role-based access control (RBAC)
- Predefined roles: Owner, Admin, Developer, Viewer
- Organization, project, and environment-level permissions
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