Launch libraries – Dev/Staging/Prod

When I am asked what Launch is, and I want to keep it abstract, I usually say that Launch is at the base a script manager. It allows people to use a UI, and it generates Javascript, which can then be added to your web site to do stuff.



The process of generating Javascript files is called “Build” in Launch. Unlike DTM, Launch never builds unless you tell it to. DTM used to build a “staging library” whenever you saved any changes. That is not the case in Launch!

Out of the box, you would see three “Environments” in Launch:

  1. Production,
  2. Staging, and
  3. at least one Development

There can be as many development Environments as you need. If you have three colleagues who tend to work in Launch, you should assign each their own dev Environment.


Because when you build, the Javascript code gets bundled and added to one of the Environments.

How does it get bundled?

Well, a Launch user can decide to create a “Library”, and they can add elements to that Library, usually changes they have just made.

If I log into Launch, change a Data Element and a Rule, my next step is to create a Library, attach it to my dev Environment, add the two changes, build and then test it.

Apart from the two changes I added to my Library, “everything that is currently in production” will also be in it.


When Launch builds my Library, it uses the latest published Library as the base, then adds my changes.

This, btw, is why you cannot delete things in one go! There would be a risk of pulling elements from under the feet of others, hence the disable-publish-delete-publish flow.

You’d create and assign each of the three colleagues their own Environment, because that way, they can make changes mostly without stepping on each others’ toes.

Note that this is limited to them working on separate elements. If two of them change the same Rule, they will both have to add that same Rule to their Libraries, and probably also other elements that played a role in the changes.

If I create a Data Element “Page Language” and add it to the “All Pages | None | DOM Ready | [AA,AT]” Rule, and you create a Data Element “Page Template” and add it to the same Rule, we will both have to add all three changes into our Libraries.


When you first create a Launch Property, it is best practice to immediately create a Library, add something (maybe just the Core Extension) to it, build, approve, publish.

That way, when you embed any Environment into any site (we get to that), there will be code available and you won’t see a 404 error.

When you have created and published your first Library, you can safely embed all Environments into any sites. Yes, including staging and all dev Environments.

When Launch is instructed to load any Environment, it will use fallbacks as necessary.

  • Tell it to load the prod Environment, and it’ll do just that, or fail with a 404 if no Library has ever been published.
  • Tell it to load the staging Environment, and it’ll do just that, or load the prod Environment if there is currently no Library in the staging Environment.
  • Tell it to load a dev Environment, and it’ll do that, or fall back to staging, then prod, if necessary.

Makes sense?

Quiz. In the screenshot here, which Libraries are loaded?

Library Publishing Quiz
  1. On a page that embeds the Production Environment, which Library is loaded?
  2. On a page that embeds the Staging Environment, which Library is loaded?
  3. On a page that embeds the “Dev2” Environment, which Library is loaded?

What do you think?

The answers are: “test”, “test”, and “Blog test 2”

What about “Blog test 1?” you ask?

Well, look at the little dots, or the Environment.

Libraries don’t have to be attached to any Environment!

If you see a green dot, or if there is an Environment listed, then the Library is available. If the dot is orange, and the Environment says “None”, then it isn’t.

Libraries not attached
In real life, the Staging Environment will only very rarely contain a Library.

That Library usually gets there when someone wants to explicitly test the Library, and they therefore use the “Build for Staging” menu item.

Build for Staging
You can then immediately see the display change, even while the Library is building.

Build for Staging in progress
And once it is done, you’ll see the green dot.

Build for Staging complete
Publishing follows the same pattern. Once the Library is approved, it is not attached to any Environment, until someone uses the “Build & Publish to Production” menu item.

Build & Publish to Production
And now you know why the fallbacks exist and are important!

And you can also guess that when you work on something but need to focus on something else for a moment, you can do something similar to a stash, simply by detaching your current dev Library from your dev Environment, creating a new one, working on that until done, then re-attach your old Library back.


DTM used to simply build the staging environment whenever you saved any changes.

Since that is very convenient, you can also do something similar in Launch.

The concept is called a “Working Library”, and you can find it at the top right of the Launch UI.

When you designate a Library your Working Library, all “Save” buttons in Launch will instead become “Save to Library and Build” buttons or “Save to Library” buttons.

That means that Launch will build your Library whenever you save a change, and you don’t have to manually trigger it.

There is also a nice, new “Build” button next to your Working Library on every screen in the Launch UI, for even more convenience.


With DTM, I once told you to always embed the production code.

DTM’s trigger-happiness for dev Library builds was the reason for that. In my opinion, no site, dev, UAT, staging, whatever it would be called, should ever, by default, embed potentially broken code.

With Launch, that is now solved!

You embed the production Environment on your production web site, and the staging Environment everywhere else.

If any of your developers want to embed a dev Environment, then I would seriously wonder whether they would actually be both, a Launch user and AEM dev. Otherwise it would make no sense for them to embed dev.

The good thing about embedding a staging Environment: most of the time, it’ll be the production code. And when someone wants to approve, they can do so simply by building the Library in Launch for the staging Environment.

By the way: Launch is smart enough to handle the fallback in a way that makes sense.

Example: in the Analytics Extension, you can assign different Report Suites for dev, staging, and production Environments. That way, data from test or staging systems doesn’t “pollute” your production data.

This works in cases of fallback. When you tell Launch to load the staging Environment, it’ll pretend to do so even if it falls back to production. From the point of view of Analytics, it’ll be the staging Environment.

Cool, hm?

And much easier then with DTM, I think!

Author v Publisher

With AEM, every site you build exists twice: you have a publisher, which hosts the site as visitors see it. And you have an author, on which your colleagues create and edit content.

The past and current integrations between AEM and DTM/Launch have treated author like publisher, meaning you were able to deploy the Launch production Environment on author.

In my (humble?) opinion, it would make more sense to deploy a different Launch Property on author. While I want to be able to analyse visitor behaviour on the live site (on publisher), on author I would probably want to know how the content authors edit and create, and so the setup would be very different.

Right now, with the integration as it is, I would probably not deploy on author at all.


If you look at the big picture, this is what you should see:

  • 3 environments in AEM: production, staging/UAT, dev
  • 1 publisher per environment, plus 1 author, so 3 publishers & 3 authors
  • 1 Launch Property
  • 3 or more Launch Environments: productions, staging, 1 or more dev
  • Launch production Environment embedded on AEM production publisher
  • Launch staging Environment embedded on AEM staging/UAT and dev publishers
  • No Launch embedded on the 3 authors
  • 2 Report Suites in Analytics, 1 production, 1 dev
  • Analytics Extension in Launch configured to send data to production Report Suite in production Environment
  • Analytics Extension configured to send data to dev Report Suite in dev and staging Environments

And that’s it. Easy!

6 thoughts on “Launch libraries – Dev/Staging/Prod

  1. This new flow has definite advantages, but also some drawbacks for large enterprise companies. We really struggle with only allowing a single Library in Staging. Another challenge is not having an automated way to combine Libraries and conversely pull Libraries out of a combined Library. We are looking at using the API to help manage this better, as what is there in the Launch UI is very limiting for us. Happy to talk about this in more detail if you’re interested.


    1. Hi Cleve,

      Love to see your opinion and experiences with large scale working with DTM and Launch! I had hoped you’d contribute!

      I agree with you that having the ability to queue more than one library for staging would make sense, especially when combined with some automation.

      I’m less sure about merging. I see staging from the perspective of “fail fast” (as in: whoever looks at it should quickly send back the library if in doubt), and the smaller the changes, the easier to check them, resulting in faster turn-around.

      Using the API might help automate some of that. Ping an approver as soon as there is a lib in staging, help them go to the right page and test, maybe?

      I think the reason why there is only one staging lib at a time has to do with merges and fallbacks. If you had multiple staging libs, then what would be the “current state” to be used for all the new dev libs?


      1. We have two main issues (some other minor ones) with a single Library for Staging:

        1) It’s common for people outside of our group to have to help us do QA. This could be someone from another internal group or an external vendor. Asking them to use Experience Cloud Debugger, Launch Switch, or some other URL switching tool to load a Launch Development Evironment is impractical. So often we are left with juggling moving a particular Library in and out of Staging as we try to get others to test, while at the same time having to another group test a different Library in Staging, and also go through our normal publishing process for other Libraries to get them to Production.

        I recently went through this where a different, non-tech savvy group in Asia took over a week to QA their Library. Because they work on a different schedule I was constantly moving this Library in and out of Staging so we could get other Libraries tested and published. It became a communication headache and confused time suck.

        2) Code conflicts. While not that common for us, it does happen where code between two separate Libraries can have a conflict. You don’t see this when testing them in isolation, it’s only when they are working at the same time that you catch the conflict. I’ve had this happen a couple times and we didn’t catch it until it was already in Production (thankfully very minor issues). Not good.

        We have 3 developers currently working in Launch. I’ve so far been very restrictive about giving others access, although they keep pushing me for it and at some point we will need to open this us to more. At any one time we may have 20+ Libraries in Development because of the large number of requests we handle. Last week I had to create a Development_Library_30 environment because we had so many jobs still open that week. Managing that volume with a single Staging Library has proven to be challenging.

        My “plan” for Jan/Feb is to build an API process that allows us to manage moving multiple Libraries into and out of Staging. I’m still working through exactly how this will work, as it’s not as simple as “merging” Libraries and moving them into/out of Staging. My initial thought is to list all Dev Libraries, and then allow a user to combine whichever Libraries they want. If there is already a Library in Staging it will list which Libraries have been combined into it, so hoping the new Library specific NOTES are availabe via the API(?!?!). It will add the LIbraries you select to the current Staging Library, or create a new one if nothing is in Staging. Then, when you want to pull that Dev Library out you would select it and tell the system to remove it from the bigger Staging Library. Of course the complexity comes in checking all the elements in the Staging Library to make sure they are not needed for other Dev Libraries which have been combined into the staging library. Again, we’ll see how practical that turns out to be.

        Once we start working on that and get a prototype built I’ll let you know.


      2. I like your “plan”. Not sure it’ll be feasible, but we’ll see.

        The notes should be available in the API. I’m thinking that because everything in Launch is API first…


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.