Security
Security at Muerte Cloud
How the platform protects your traffic, your data and your account — and which parts stay your responsibility.
Shared responsibility
Muerte Cloud handles
- Physical and network security of the underlying infrastructure
- TLS termination and certificate issuance for your domains
- Edge filtering of volumetric and application-layer attacks
- Isolation between services running on shared hosts
- Backup scheduling, storage and restore tooling
- Patching the build and runtime images we provide
You handle
- Application code, dependencies and their vulnerabilities
- Authentication and authorization inside your app
- Keeping secrets in environment variables, not in the repository
- Access to your Git provider and your Muerte Cloud account
- Verifying that your backups restore the data you need
- Data you choose to collect and how long you keep it
How it works
Network and TLS
- All external traffic is served over HTTPS; certificates are issued and renewed automatically.
- Apex domains, subdomains and wildcards are supported, including proxied setups.
- Private services are reachable only from inside your project network, never from the public internet.
DDoS protection
- Volumetric attacks are absorbed upstream, before traffic reaches your container.
- Application-layer filtering is enabled for every public service by default — nothing to configure.
- You can add rate limiting and caching in your own application on top of that.
Isolation and runtime
- Every service runs in its own container with its own filesystem and process namespace.
- Builds run separately from the running service; a failed build never replaces a healthy one.
- Containers receive SIGTERM and a drain window on redeploy, so in-flight work finishes cleanly.
Secrets and variables
- Environment variables and secret files are stored outside your repository and injected at deploy time.
- Secret values are write-oriented in the panel: they are set and replaced, not browsed as plain text lists.
- Environment groups let several services share one set of values without copy-pasting.
Data and backups
- Volumes and managed databases can be backed up on a schedule or manually at any time.
- Backups are stored separately from the service that produced them and can be restored to a chosen copy.
- Retention depth is configurable per schedule, so you decide how far back you can go.
Operations and visibility
- Build and runtime logs, resource metrics and health checks are available per service.
- Deploy, service and billing events raise notifications so failures are not silent.
- Destructive actions in the panel require explicit confirmation, including when triggered by an AI agent.
Subprocessors
The infrastructure vendors we rely on to run the platform. The list is updated whenever it changes.
| Company | Purpose | Location | Additional details |
|---|---|---|---|
| Cloudflare | Content Delivery Network | Global (incl. EEA) | www.cloudflare.com/trust-hub |
| Cloudflare | DDoS protection | Global | www.cloudflare.com/ddos |
| Gcore | DDoS protection | Global (EU-operated) | gcore.com/ddos-protection |
| Selectel | Content Delivery Network | Russia | selectel.ru/services/additional/cdn |
| Selectel | Hosting / Cloud Platform | Russia | selectel.ru/services/cloud |
| Selectel | Cloud Storage | Russia | selectel.ru/services/cloud/storage |
| Timeweb | Cloud Storage | Russia | timeweb.cloud/services/object-storage |
| Unisender | Email processing | Russia | www.unisender.com |
Reporting a vulnerability
If you believe you have found a security issue, email [email protected] with the details. We read every report and reply to the ones that include enough information to reproduce the problem.
- Describe the affected URL or service and the exact steps to reproduce.
- Do not run load or denial-of-service tests against production.
- Do not access, modify or exfiltrate data that does not belong to you.
- Give us reasonable time to fix the issue before publishing details.