High Availability
Edge's built-in redundancy and how to design your applications for resilience when things fail.
Edge's built-in redundancy
The CDN is deployed across 2,200+ locations worldwide. When a user requests content, they're routed to the nearest edge node. If that node fails or is congested, traffic is automatically rerouted to another node — no configuration required.
DNS uses anycast: the same hostname resolves to multiple IPs, and users hit the closest responder. Geo-routing directs users to optimal regions based on their location. Edge handles this at the infrastructure level.
Designing for resilience with multiple VMs
For critical applications, run multiple VMs behind a load balancer or use the CDN to distribute traffic. If one VM fails, the others continue serving. Ensure your application is stateless or shares state (e.g. via a database) so any VM can handle any request.
Use health checks: configure your load balancer or CDN origin to probe your VMs and stop sending traffic to unhealthy instances. This accelerates failover and prevents users from hitting broken nodes.
Using the CDN as a shield for your origin
Put the CDN in front of your origin (VM or storage). The CDN absorbs traffic spikes, DDoS attempts, and reduces load on your origin. Even if your origin goes down briefly, cached content can still be served from the edge.
Configure appropriate cache TTLs so static content is served from edge during origin outages. Dynamic content will fail, but a partially working site is better than complete downtime. See Caching Strategies for tuning.
DNS failover concepts
Geo-routing — Edge DNS can route users to different origins based on their geographic location. This is a real feature today: configure regional records and users are directed to the closest or preferred endpoint.
Health-check-based DNS failover — Automatically switch DNS to a backup origin when the primary fails health checks. This is not yet implemented on Edge; we're working on it and will announce when it's available. For now, manual DNS changes or third-party DNS services can provide failover if you need it.
Automated backups and snapshots
Take regular snapshots of your VMs. In the control panel, use Compute → Snapshots to create point-in-time backups. Schedule them via cron or automation — daily or weekly depending on how much change you can afford to lose.
For storage buckets, enable versioning where supported, and consider cross-region or off-platform backups for critical data. Test restore procedures so you know they work when needed.
Monitoring and alerts
Set up monitoring for your VMs, CDN, and DNS. Use the control panel metrics, and integrate with external tools (e.g. UptimeRobot, Pingdom) for external health checks.
Configure alerts for high error rates, latency spikes, and resource utilisation. Responding quickly to degraded performance reduces impact. Review the Status page (edge.network/status) for platform-wide incidents.
What happens during CDN node failure?
If an edge node fails, traffic is automatically rerouted to the next nearest node. Users may see a brief latency increase during failover, but service continues. The CDN is designed for no single point of failure.
Origin failures are different — if your VM or storage goes down, uncached requests will fail. That's why we recommend multiple origins, health checks, and good caching for cacheable content.
Planning for maintenance windows
When you need to update your application or VM, plan for minimal disruption. Deploy to a new VM first, then switch traffic (load balancer, DNS, or CDN origin). Alternatively, use rolling updates if your orchestration supports it.
Edge publishes planned maintenance on the Status page. Schedule your own maintenance during low-traffic periods and communicate with users in advance.