Documentation

Learn how to build, publish, and launch your site with Adobe Experience Manager.

Resources

Create your site

Adobe Managed CDN

The following steps illustrate how to use the Adobe Managed CDN (part of Edge Delivery Services entitlement) to configure a property to deliver content from a site powered by Edge Delivery Services in Adobe Experience Manager Sites as a Cloud Service.

Prerequisites and limitations

Before you go live

There are two deployment options for going live with Adobe Managed CDN

  1. Setup an HTTP proxy from an existing AEM Sites as a Cloud Service environment. This is typically used when you already have an existing environment and you want to migrate part of a site to Edge Delivery Services. You can also add a new environment.
  2. Setup a new Edge Delivery site independently of an AEM Sites as a Cloud Service environment. This is the approach used when you do not have an AEM author or publish environment and you want to use Edge Delivery Services on its own. See here for benefits.

A checklist of the steps you need to do for both options:

  1. Install or request a certificate in Cloud Manager (you need to do that for both www and non-www apex domains)
  2. Install the domains Cloud Manager (you need to do that for both www and apex domains)
  3. Add a CDN configuration to map your domain to your Edge Delivery site. (This will be done differently depending on what deployment option you chose).
    Make sure that any production setup maps to the main branch of your Edge Delivery origin, meaning that your origin hostname starts with main-- to allow for caching and push invalidation of content changes..
  4. Setup push invalidation in the project's configuration
  5. Point the DNS CNAME of your www site to cdn.adobeaemcloud.com and the A records of your apex to the IP addresses listed below.

(Option 1) Setup a proxy from an existing environment

This requires an existing AEM Sites as a Cloud Service environment that needs to be configured via configuration pipeline to proxy some (or all) paths on your domain to your Edge Delivery Site. (see how to define a proxy using originSelectors and how to run a Configuration Pipeline).

A redirect from https://example.com to https://www.example.com must be defined using a redirect rule, but all other redirects may use the redirects spreadsheet

(Option 2) Setup an Edge Delivery site without an existing environment

In case you do not have an existing authoring/publish environment, follow the steps for setting up a new Edge Delivery site in Cloud Manager.

An automatic redirect will be established from https://example.com to https://www.example.com but all other redirects must happen through the redirects spreadsheet.

Setup push invalidation for Adobe Managed CDN

Push invalidation automatically purges content on the customer's production CDN (e.g. www.yourdomain.com) whenever content or code changes are made on AEM origins with the main branch in the host name (e.g. main--site--org.aem.live). Changes pushed to other origins do not trigger push invalidation.

Content is purged by URL and by cache tag/key.

Push invalidation is enabled by setting up the CDN section of the configuration service.

curl --request POST \
  --url https://admin.hlx.page/config/{org}/sites/{site}/cdn.json \
  --header 'content-type: application/json' \
  --data '{
	"prod": {
		"host": "{production host}",
		"type": "managed"
	}
}'

Configuration properties:

key value comment
host <Production Host> Host name of production site, e.g. www.yourdomain.com
type managed

An optional envId property (format: pXXXX-eXXXX or or pXXXX-dXXXX) can be added if a large number of sites share the same repoless content origin. By setting a common envId, cache purge invalidations triggered by content changes are collapsed into a single purge request rather than firing separately for each site, improving efficiency and reducing redundant invalidation calls.

Note: The envId property is not needed for standard setups. and should be left unset in most cases. If you are unsure whether your setup requires it, contact Adobe.

(Optional) Lower the TTL of existing DNS records before going live to enable a faster rollout

If the DNS records for your go-live domain have a long time-to-live (TTL)—such as 12 hours or more—you may want to temporarily lower the TTL (for example, to 1 hour or even 60 seconds) to speed up site rollout. Doing so ensures traffic is routed to the new site more quickly after launch. Be sure to restore the original TTL value when updating the DNS records for go-live.

As you go live

Make or request following DNS change:

If you want to establish an automatic redirect from https://example.com to https://www.example.com, the following additional steps are required

Depending on your DNS setup—including the TTL specified in your DNS records—changes can take anywhere from a few minutes to several hours to propagate. If your site already receives traffic, ensure all redirects are configured or keep the existing site live until the TTL expires and all traffic is routed to the new site.

If you are hosting both the apex and www versions of the domain, make sure DNS is properly configured for both to enable certificate generation.

For a timed launch, consider setting up a temporary holding homepage that you can quickly replace with the final content at the launch time. Because publishing in AEM is fast and reliable, this approach gives you better control over when your content becomes publicly visible than relying solely on DNS changes.

After you go live

The AEM team reviews your setup and notifies you if any issues are found.