Skip to main content

The Radix clusters

Your application(s) will run in a Kubernetes cluster. Radix currently have four clusters: Platform (North Europe), Platform 2 (West Europe), Platform 3 (Sweden Central) and Playground. Use Playground for testing Radix and see if it's a good fit for your needs. When your project and team are happy with Radix, you should register your application to one of the Platform clusters, which provides specific guarantees.

ClusterAzure RegionDNS ZoneLinks
Platform (North Europe)North Europeradix.equinor.comAPI / Web Console
Platform 2 (West Europe)West Europec2.radix.equinor.comAPI / Web Console
Platform 3 (Sweden Central)Sweden Centralc3.radix.equinor.comAPI / Web Console
PlaygroundNorth Europeplayground.radix.equinor.comAPI / Web Console
Moving applications between clusters

Currently, there is no automated process of moving an application between clusters. To move an application, you must manually register it in the new cluster. We have provided a suggested checklist below.

Move an Application between Radix Clusters

Register the Application

  • Create the application in the target Radix cluster using radix-cli or Radix Web Console

Run Initial Build/Deploy Pipeline

  • Trigger a CI/CD pipeline to build and deploy all environments (dev, QA, prod)
  • Validate that images are built and components are available in Web Console

Update workload identity

Update Environment Variables & Secrets

  • Recreate secrets in the Web Console (Radix does not migrate secrets automatically)
  • Validate all environment variables match the old cluster setup

Update OAuth Configuration

  • Adjust redirect URIs in App Registration for the new cluster endpoints
  • Test authentication flows
  • Set up new Private Endpoints for services that require secure connectivity
  • Validate DNS resolution and connectivity

Set Up External DNS & Certificates

  • Configure new External DNS records for the application
  • Configure the automated certificate option

Update Firewall Settings

  • Add new cluster IP ranges to any firewall rules
  • Remove old cluster IPs once migration is complete

Test Everything

  • Validate application functionality in all environments
  • Check logs, integrations, and external dependencies

Switch Traffic & Decommission Old Cluster

  • Update DNS or routing to point to the app in the new cluster
  • Monitor for errors during cutover
  • Remove the app from the old cluster once stable