Lumen help
Lumen uses DNS to route requests to the most appropriate data center. When you sign up for Lumen® Application Delivery Solutions, you configure a CNAME record to point your traffic to our edge, just like a traditional CDN. Lumen also includes a global anycast DNS network. This can be useful if you run your site as a bare domain. While you can choose to move your DNS to our nameservers, that’s optional.
Learn more about Lumen HTTPS options and capabilities
When you want to add a domain to Lumen, it is sometimes unclear where that domain should fit into your existing account, application, and environment structure. This guide will help you decide whether it is most appropriate to create a new application, create a new environment, or add a new domain to an existing environment.
My new website is a staging/UAT site for a production site that I have running or want to run on Lumen
The purpose of the Lumen application-environment structure is to streamline the configuration testing and promotion process for modules in your stack. With respect to configuration, the definition of an application is a git repository, and the definition of an environment is a branch within that repository. This makes testing changes to the staging environment and then promoting them to the production environment as simple as a git merge and push.
If you want to add a staging site to Lumen, the best solution for most use cases is to add a new environment to the same application (or use the staging environment that comes by default whenever you create a new environment).
Summary: we recommend adding a new staging site to an existing application as a new environment.
I want to add a new website to Lumen that is similar to one or more sites I already have running on Lumen
Lumen maintains running containers for each module in your stack in each point of presence on a per environment basis. That means that if you assign www.example.com and www.demonstration.com to the same Lumen environment, the same containers will handle traffic for both sites. If you have a new site that has similar needs and configuration patterns to a site that is already running on Lumen, then assigning both domains to the same environment greatly simplifies the overhead of managing them.
When two sites have the same URI patterns for resources and routes that should and should not be cached (i.e. both are set up for HTML caching and use the same routes for admin functionality or checkout), then it often makes sense to assign both of these domains to the same environment.
It is even possible to assign two domains to the same environment when the websites are running on different origin servers. Lumen supports routing requests to alternate origins based on the incoming request’s hostname or other criteria.
If the websites are mostly the same but have a few important differences, you can manage this as well within a single configuration by building hostname specific logic into your Varnish cache configuration:
Summary: If two websites have similar CDN/Edge compute needs, they should be mapped to the same environment.
I want to add a new website that is very different from all the sites I have running on Lumen
If you want to add a new site that has different needs from all the other sites you have running on Lumen, then creating a new application is often the best choice. As mentioned previously, one application corresponds to one git repository, so you will be able to manage the configuration for these two sites independently of one another. Some example use cases include:
Note that it is possible to set up a new domain as another environment within the same application (Lumen supports multiple environments with names other than Staging or Production). While this allows all of your sites to share one git repository (a fact which does not particularly benefit you if the sites are different enough to not be mapped to the same environment), your sites will also share the same Kibana logs—meaning that logs from site A will be mixed in with logs from site B.
Summary: If two websites have different configuration needs or require different modules to run in the stack, these two domains should be in separate applications.