Installing specific versions of extensions in Lucee 5.2.x

Is there a way to uninstall specific extensions using the same mechanism?

Are there any docs about what each of the environment variables do? I am still trying to install the extension as defined by the the LUCEE_EXTENSIONS variables but it doesn’t seem to be working on Lucee

Some docs and clarity outside the LAS team members would be nice.

docker compose example:

version: "3"
    image: ortussolutions/commandbox
      - ".:/app"
      - 8080
      - LUCEE_EXTENSIONS="16FF9B13-C595-4FA7-B87DED467B7E61A0;name=Memcached;version="
1 Like

With Docker it’s important that extensions are installed during the image build for a number of reasons (container startup time, removes the dependency on the extension server being contactable, consistent/repeatable builds, etc), so I’d avoid adding the LUCEE_EXTENSIONS environment variable to the Docker Compose file if possible since they are kind of run-time settings.

I think this is the most basic, working example that I can give as a starting point for installing Memcached, and then configuring it as a session store;


FROM lucee/lucee52:latest

# install extensions by prewarming lucee
ENV LUCEE_EXTENSIONS "16FF9B13-C595-4FA7-B87DED467B7E61A0;name=Memcached;version="
RUN /usr/local/tomcat/bin/

COPY www /var/www


  build: .
    - "/workbench/memcached/www:/var/www"
    - "8888:8888"
    - "memcached:memcached"
  image: memcached:alpine
    - "11211"

(Note: Your volume paths may vary, the above is just what works for me in my environment).


component { = "memcached";

	this.cache.connections["sessions"] = {
		class: "",
		bundleName: "memcached.extension",
		bundleVersion: "",
		storage: true,
		custom: {
			"servers": "memcached:11211"
		default: ""
	this.sessioncluster = true;
	this.sessionstorage  = "sessions";



<cfparam name="session.timestamp" default="#now()#">
<cfdump var="#session.timestamp#">

To test;

  1. Start the containers in the background with docker-compose up -d.
  2. Browse to the index of the app and a timestamp will be written to the session which will be stored in memcached.
  3. Restart just the Lucee container with docker-compose restart lucee
  4. Browse to the index of the app again and you should see that the timestamp remained the same, which means that the session was successfully persisted in memcached across Lucee restarts.

If you’re using CommandBox Docker images I don’t know the most efficient way of installing/prewarming Lucee there, there’s perhaps a command that will start and stop the server for you. I would start with barebones Lucee Docker images to prove it’s working, and then move back up the chain up from there.

Hope that helps :smiley:


This post makes reference to a spreadsheet tracking the state of all config options:

What do you have in your script? is it

 RUN rm -rf /opt/lucee/web/logs/ && \
   /usr/local/tomcat/bin/ start && \
   while [ ! -f "/opt/lucee/web/logs/application.log" ] ; do sleep 2; done && \
   /usr/local/tomcat/bin/ stop

Yep, you can see the source here:

1 Like

Hi @markdrew I just noticed your comment. I don’t know if you figured it out, but the env var LUCEE_EXTENSIONS is not what Lucee proper looks for. I believe that name is specifically something looked for in the official lucee image that gets passed through to an env var or JVM prop of the name Lucee is actually looking for which is either lucee-extensions (deprecated) or lucee.extensions

The CommandBox image doesn’t provide a passthrough env var called LUCEE_EXTENSIONS. We could, but I’m not sure what the point would be since it’s almost exactly named as the built in env var, just non-standard. With the CommandBox image, just provide the environment variable in the format Lucee itself is looking for and everything should work.

Also, FWIW, since these links are so hard to find, I’ll leave them here as well. Here’s the docs for that env var (which seriously needs some love since it doesn’t even cover specific versions!):

And here is the “living” Google Doc that lists all possible env vars and system props. The one in question is on line 5.

The Lucee settings that come from Java system properties are also supported as environment variables. From my original post above;

This means that the Java system property lucee.extensions can instead be specified as the environment variable LUCEE_EXTENSIONS, and the same should apply to all the other properties that are listed in the above spreadsheet :slight_smile:

Edit: just to clarify, the Lucee docker images don’t do anything special to find and pass through these environment variables as system properties, they are supported directly by Lucee and should work anywhere AFAIK.


We use

ENV LUCEE_EXTENSIONS "66e312dd-d083-27c0-64189d16753fd6f0;name=PDF;version=,99a4ef8d-f2fd-40c8-8fb8c2e67a4eeeb6;name=MSSQL;version=6.2.2.jre8"

In our Dockerfile and that seems to work, as once we’ve prewarmed saved the image then spun the image up, going to the extensions area shows these as up-to-date.

It would be really good if Lucee would either use ExtensionStore ID’s as you are doing or forgebox stubs, I think this would look better no?

ENV LUCEE_EXTENSIONS pdf@, memcached@

Since using the UUID is such a pain for admins etc that would look at a random docker file (like I have) :

FROM ortussolutions/commandbox

Prizes for anyone to know what extension that is :slight_smile:

At the end of the day, the point of this is to make configurations easily readable by humans.

In summary, add stub names for the existing extensions (store, since that is where they come from), if not found, look for them in

steps off soapbox

1 Like

Mine looks like

ENV LUCEE_EXTENSIONS "66e312dd-d083-27c0-64189d16753fd6f0;name=PDF;version=,99a4ef8d-f2fd-40c8-8fb8c2e67a4eeeb6;name=MSSQL;version=6.2.2.jre8"

And that appears to install, whilst I can at least see what it’s going to do…

I get you, I see what it’s going to do, but it’s an abusive way to do it for the poor sys admin that I am going to hand off the docker file to.

And then I tell him about the box.json file that also downloads dependencies etc. I know you can read it but there is usually a chain of people that need to know this.

(I wasn’t having a go at you sir, just the implementation)

Micha explained above the reason for the current implementation is that it matches the OSGi syntax that is used in the manifest files for installing extensions;


It’s not the nicest thing to read but the name and/or label does make it human readable, and I’m ok with it at least being consistent with what is already used in the manifests.

That said, I’d be happy to see a new identifier that wasn’t a UUID if Micha thinks that’s feasible to support :slight_smile:


FWIW, when using the CommandBox Lucee images, here’s the approach we take to bypass using the environment variables, but still install the extensions we need:

1 Like

Awesome project @mjclemente!

by setting “lucee.extensions.install” to false, the extension defined in the manifest not get installed, that way only extension defined with env variable get installed

Such a nicer solution

Circling back to your initial post here; just out of curiosity, does the version of the Memcached plugin cause an issue for you?

Or was that example purely for the sake of example?


1 Like

My original post? No, no issues at all with specific versions of the extension. I was just after some confirmation on those 3 points;

  1. Can we pin the version number of an extension at install time (answer is yes)
  2. Why do automatic upgrades of plugins happen (answer, because they are available and the version is not pinned)
  3. Can we turn off automatic upgrades of extensions (answer seems to be yes if you set “lucee.extensions.install” to false though I haven’t tested this, OR you pin the version in the LUCEE_EXTENSIONS env var, OR you have the versions specified in the lucee XML files).

The reason behind all of that is that I need the extension installation to happen at build time in Docker images, so that I can have repeatable builds that always produce the same result, rather than having unexpected things like extension installation/upgrades happen during container startup. So for the past 15+ months we’ve been in a pretty good place I think :smiley:


“lucee.extensions.install” is a nice trick… but it’s not documented here:

Is it an official feature?