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!

2 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?


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 )

Google photo

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

Twitter picture

You are commenting using your Twitter 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.