Go Live guide

Welcome to the DX Cloud Go Live Checklist.

This guide is here to ensure a smooth and successful deployment of your project into production. Each point in this checklist addresses critical aspects that need to be reviewed and confirmed before the "Go Live" date.

From infrastructure readiness to automation, we walk you through the essential steps, providing clarity on where to assess each item and noting automation opportunities for streamlined processes.

Pre Go-Live Check

You need to submit a Pre Go-Live Check (PGLC) request at least 5 business days in advance for standard projects. More complex setups may require additional time. While we strive to accommodate your preferred dates, availability is not guaranteed.

By following this checklist, you’ll be fully prepared to confidently deploy your project. Be sure you complete this checklist before requesting a PGLC.

Request Pre Go-Live Check

Standard project checklist

There are several items that need to checked before you go live. Completing this list does not necessarily mean going live will be entirely successful, but it helps minimize potential deployment issues.

The checklist is interactive, so you can use this page to tick each item off your list as you go if so desired.

Administration

  • You have established contacts for emergency site situations including primary technical contacts for your project and this has been communicated to the DX Cloud team.

  • The superuser credentials such as the secret and password have been updated for production including for both Public and Author instances.

Architecture

  • Your Magnolia pods and database pods for PostgreSQL are on the same node.

    For more on this topic, see Kubernetes fundamentals.

  • Your Magnolia Public instances are running in different availability zones. This helps to minimize any potential down time for your site.

    For more on this topic, see Multicluster environments.

Database and memory

  • You use PostgreSQL 15 or later.

  • Database persistent volume for Magnolia is less than 50%. If there is an issue with persistent volume, see Database persistent volume is almost full.

  • You have at least 2 Magnolia public instances.

    For more on this topic, see Architecture: Deployment options.

  • You have a minimum 6gb JVM Max Heap available for public instances.

    Having less than 6gb JVM Max heap can cause issues like a container being OOMKilled.

  • You have at least 4gb available to public instances. (excluding Max Heap)

  • You have a minimum 8gb JVM Max Heap available for author instances.

    Having less than 8gb JVM Max heap can cause issues like a container being OOMKilled.

  • You have at least 4gb available to author instances. (excluding Max Heap)

  • Your Magnolia instances do not have a CPU limit set.

    For more on this topic, see CPU requests and limits on DX Cloud.

  • Your memory request and memory limit are the same.

    Why is this important?

    If you set a lower memory request than a memory limit, Kubernetes might run your Magnolia instance or Magnolia frontend instance on a cluster node that has enough memory to meet the memory request but not have enough memory to provide all memory of the memory limit.

    For Magnolia pods, you can set the memory request and limit used for the Magnolia author and public through the Helm chart values.

Helm

  • You do not use a custom helm chart.

    You must use the offical DX Cloud Helm chart.

  • You use a recent Helm chart version that is applicable to the version of Magnolia you use in our project.

    The latest Helm chart version is 1.17.2.

Monitoring

  • You have defined the JMX jar and JMX configuration in CATALINA_OPTS.

    For more on this topic, see JMX Monitoring.

Networking and infrastructure

  • You do not use JCR clustering.

  • You use the standalone redirects server.

    For more on this topic, see Networking: Add redirect server.

  • If you are using the DX Cloud CDN, check with your DX Cloud contact to ensure we have set up the service. Be sure you are connected to Fastly.

  • Ensure the Web Application Firewall (WAF) is set up and ready. You can contact your DX Cloud representative to be sure of this.

  • Ingresses serving life traffic must have Fastly annotations (if using DX Cloud CDN).

  • You do not use snippets in your values.yml file.

    All ingress updates should go through the values.yml file as per the official Helm chart.

  • Adjust TTLs

    To ensure a smooth transition during go-live, it is important to adjust the TTL (Time to Live) values for the DNS records of the domains being migrated to Magnolia DX Cloud.

    TTL determines how long DNS records are cached by DNS servers and clients. Lowering the TTL ensures faster propagation of DNS changes during initial deployment, minimizing potential disruptions.

    After a successful Go-live, the TTL can be increased to reduce the load on DNS servers.

    1. Check the current TTL settings for all domains.

    2. Reduce the TTL to a lower value, such as 300 seconds (5 minutes), at least 2 * current TTL before the go-live date.

      For example: If the current TTL is 24 hours (86400 seconds), lower the TTL 48 hours before go-live.

    3. Perform necessary DNS updates (e.g., pointing the domain to Magnolia DX Cloud or to the CDN provider) during the go-live window. With a lower TTL, changes will propagate quickly.

    4. After confirming a successful go-live, increase the TTL back to its original or a higher value to optimize DNS server performance.

      Example timeline ::

      • Current TTL: 24 hours (86400 seconds)

      • Go-live date: January 15, 2025

      • Action: Lower TTL to 300 seconds on January 13, 2025 (48 hours before go-live).

    After completing these steps, the domain transition to DX Cloud will be seamless and efficient.

Configure IP Whitelisting with Fastly for Go-Live

This section explains how to configure IP whitelisting with Fastly to secure access to DX Cloud instances. IP whitelisting ensures that only authorized IP addresses can access your Magnolia cluster, enhancing security for both public and internal use cases.

  • Public instances (e.g., example-domain.com): Customer-facing sites restricted to specific client IP addresses via Fastly.

  • Author instances (e.g., author.example-domain.com): Editorial environments restricted to internal or client IP addresses.

Why switch domains and configure IP Whitelisting?

At Go-Live, customers switch from temporary or staging domains to production domains to achieve the following:

  • Branding: Use your branded domain for public-facing sites, replacing temporary domains like magnolia-platform.io.

  • Security: Fastly’s Access Control Lists (ACLs) restrict public instance access to authorized client IP addresses, protecting sensitive content. Author instances are limited to internal IPs for editorial security.

  • Performance: Fastly’s CDN optimizes content delivery for public instances, requiring DNS to point to Fastly’s edge network.

  • Environment Isolation: Distinct domains for author instances segregate editorial access, ensuring only authorized users can manage content.

IP whitelisting with Fastly and Kubernetes ingress ensures that only trusted IP addresses can access your cluster, aligning with security best practices and compliance requirements.

Configure Public instances

Public instances are customer-facing sites that route traffic through Fastly, with access restricted to specific client IP addresses.

Prerequisites

  • Collate a list of static client IP addresses authorized to access the public instance (e.g., office networks, VPNs).

You should also familiarize yourself with Fastly: Working with ACLs and Fastly’s Public IP List

Steps

  1. Prepare Client IPs:

    1. Compile a list of static IP addresses (e.g., corporate networks, CI/CD systems) that need access to example-domain.com.

  2. Submit HD Ticket for Fastly ACLs:

    1. Create an Helpdesk ticket with the DX Cloud team to add the client IPs to Fastly’s ACLs for example-domain.com.

  3. Configure Ingress IP Whitelisting:

    1. Set an Ingress annotation in your values.yml file to only allow Fastly traffic.

      You can retrieve Fastly IPs from Fastly’s Public IP List.

      Example 

      {
  "addresses": [
    "23.235.32.0/20",
    "43.249.72.0/22",
    "103.244.50.0/24",
    "103.245.222.0/23",
    "103.245.224.0/24",
    "104.156.80.0/20",
    "140.248.64.0/18",
    "140.248.128.0/17",
    "146.75.0.0/17",
    "151.101.0.0/16",
    "157.52.64.0/18",
    "167.82.0.0/17",
    "167.82.128.0/20",
    "167.82.160.0/20",
    "167.82.224.0/20",
    "172.111.64.0/18",
    "185.31.16.0/22",
    "199.27.72.0/21",
    "199.232.0.0/16"
  ],
  "ipv6_addresses": [
    "2a04:4e40::/32",
    "2a04:4e42::/32"
  ]
}

  4. Update DNS for Go-Live:

    1. Configure the DNS to point to Fastly.

      Fastly only allows connections from whitelisted client IPs, blocking all other requests.

Best practices

  • Use static IPs to prevent access issues.

  • Test ACLs in a staging environment before Go-Live.

    Test locally

    1. In your local /etc/hosts, map your domain to Fastly.

      /etc/hosts
151.101.2.132 example-domain.com

    2. Use a curl command to check the 403 Forbidden status code.

      curl -v https://example-domain.com

* Request completely sent off
< HTTP/2 403
< server: Varnish
< retry-after: 0
< content-type: text/html; charset=utf-8
< accept-ranges: bytes
< date: Mon, 09 Jun 2025 06:18:11 GMT
< via: 1.1 varnish
< x-served-by: cache-qpg1230-QPG
< x-cache: MISS
< x-cache-hits: 0
< x-timer: S1749449891.169778,VS0,VE1
< content-length: 417
<

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
  <head>
    <title>403 Forbidden</title>
  </head>
  <body>
    <h1>Error 403 Forbidden</h1>
    <p>Forbidden</p>
    <h3>Error 54113</h3>
    <p>Details: cache-qpg1230-QPG 1749449891 1824620637</p>
    <hr>
    <p>Varnish cache server</p>
  </body>
</html>

  • Monitor Fastly logs for blocked requests.

Configure Author instances

Author instances (e.g., author.example-domain.com) are restricted to internal or client IP addresses for editorial use.

Option 1: Use provided domain

  1. Deploy Magnolia Domain:

    1. Use the magnolia-platform.io domain created via the Helm chart.

  2. Configure Access:

    1. Map the domain to the author service (prod-magnolia-helm-author-svc).

  3. Configure Ingress IP Whitelisting:

    1. Set an Ingress annotation in your values.yml file to only allow Fastly traffic.

      You can retrieve Fastly IPs from Fastly’s Public IP List.

      Example 

      {
  "addresses": [
    "23.235.32.0/20",
    "43.249.72.0/22",
    "103.244.50.0/24",
    "103.245.222.0/23",
    "103.245.224.0/24",
    "104.156.80.0/20",
    "140.248.64.0/18",
    "140.248.128.0/17",
    "146.75.0.0/17",
    "151.101.0.0/16",
    "157.52.64.0/18",
    "167.82.0.0/17",
    "167.82.128.0/20",
    "167.82.160.0/20",
    "167.82.224.0/20",
    "172.111.64.0/18",
    "185.31.16.0/22",
    "199.27.72.0/21",
    "199.232.0.0/16"
  ],
  "ipv6_addresses": [
    "2a04:4e40::/32",
    "2a04:4e42::/32"
  ]
}

  4. Verify Access:

    1. Test access for authorized users via the magnolia-platform.io domain.

Option 2: Use Custom Author subdomain

  1. Create Subdomain:

    1. Define author.example-domain.com.

  2. Prepare Client IPs:

    1. Compile a list of static IP addresses (e.g., corporate networks, CI/CD systems) that need access to example-domain.com.

  3. Submit HD Ticket for Fastly ACLs:

    1. Create an Helpdesk ticket with the DX Cloud team to add the client IPs to Fastly’s ACLs for example-domain.com.

  4. Configure Ingress IP Whitelisting:

    1. Set an Ingress annotation in your values.yml file to only allow Fastly traffic.

      You can retrieve Fastly IPs from Fastly’s Public IP List.

      Example 

      {
  "addresses": [
    "23.235.32.0/20",
    "43.249.72.0/22",
    "103.244.50.0/24",
    "103.245.222.0/23",
    "103.245.224.0/24",
    "104.156.80.0/20",
    "140.248.64.0/18",
    "140.248.128.0/17",
    "146.75.0.0/17",
    "151.101.0.0/16",
    "157.52.64.0/18",
    "167.82.0.0/17",
    "167.82.128.0/20",
    "167.82.160.0/20",
    "167.82.224.0/20",
    "172.111.64.0/18",
    "185.31.16.0/22",
    "199.27.72.0/21",
    "199.232.0.0/16"
  ],
  "ipv6_addresses": [
    "2a04:4e40::/32",
    "2a04:4e42::/32"
  ]
}

  5. Update DNS for Go-Live:

    1. Configure the DNS to point to Fastly.

      Fastly only allows connections from whitelisted client IPs, blocking all other requests.

Best practices

  • Use magnolia-platform.io for faster setup.

  • Restrict author access to essential IPs (e.g., editorial networks).

  • Audit ingress rules regularly.

  • Document DNS changes in your configuration system.

Troubleshooting

  • Access Denied: Verify Fastly ACLs or ingress IP rules.

  • DNS Issues: Check CNAME records with dig or nslookup.

  • Ingress Errors: Review Kubernetes logs.

Contact the DX Cloud Helpdesk if you need support.

Additional headless checks

These checks are only if the project is a headless project or contains a headless element. They are in addition to the standard checks.

  • The service type for the frontend is clusterIp.

    A different service type can cause serious infrastructure issues.

  • You have at least 2 instances for your frontend.

Final checks

  • Your project contains only Magnolia, the redirect server, Solr (if applicable), frontend, and database deployments. No other helm deployments are allowed.

  • Check with your DX Cloud technical contact to ensure response time metrics are ready for launch.

Feedback

PaaS

×

Location

This widget lets you know where you are on the docs site.

You are currently perusing through the Magnolia PaaS docs.

Main doc sections

DX Core Headless PaaS Legacy Cloud Incubator modules