---
title: "High Availability"
description: "Design for resilience on Edge Network: built-in CDN redundancy, anycast DNS, multi-VM architecture, CDN as origin shield, backups, monitoring, and planning for failure."
url: https://edge.network/academy/high-availability/
---

# High Availability

[Back to Academy](https://edge.network/academy)
Best Practices
10 min read

# 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](https://edge.network/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](https://edge.network/compute) 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](https://edge.network/academy/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](https://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.

## Next steps

[What is the Agentic Cloud?](https://edge.network/academy/what-is-the-agentic-cloud) [Status Page](https://edge.network/status)
