I am not sure what I am doing wrong here but using "ENV LUCEE_EXTENSIONS" in my Lucee Dockerfile doesn't seem to work correctly: # List default Lucee extension IDs # https://download.lucee.org/ ENV LUCEE_EXTENSIONS="\ 37C61C0A-5D7E-4256-8572639BE0CF5838;name=ESAPI;version=2.2.4.15,\ 7E673D15-D87C-41A6-8B5F1956528C605F;name=MySQL;version=8.1.0,\ CED6227E-0F49-6367-A68D21AACA6B07E8;name=Lucee Administrator;version=1.0.0.5,\ B737ABC4-D43F-4D91-8E8E973E37C40D1B;name=Image;version=2.0.0.26-RC,\ 8D7FB0DF-08BB-1589-FE3975678F07DB17;name=Compress;version=1.0.0.15,\ 66E312DD-D083-27C0-64189D16753FD6F0;name=PDF;version=1.2.0.10,\ 671B01B8-B3B3-42B9-AC055A356BED5281;name=PostgreSQL;version=42.6.0,\ 99A4EF8D-F2FD-40C8-8FB8C2E67A4EEEB6;name=MSSQL;version=12.2.0.jre11\ " The extensions seem to be installed, but when I check the bundles - they are not loaded. Also the datasource JDBC drivers are missing and the ESAPI functions not working. Do I really have to use this code instead (which seems to work properly)? # Lucee extension & Forgebox cfspreadsheet extension (https://www.forgebox.io/view/037A27FF-0B80-4CBA-B954BEBD790B460E) ADD https://ext.lucee.org/esapi-extension-2.2.4.15.lex /opt/lucee/server/lucee-server/deploy/esapi-extension-2.2.4.15.lex ADD https://ext.lucee.org/com.mysql.cj-8.1.0.lex /opt/lucee/server/lucee-server/deploy/com.mysql.cj-8.1.0.lex ADD https://ext.lucee.org/lucee.admin.extension-1.0.0.5.lex /opt/lucee/server/lucee-server/deploy/lucee.admin.extension-1.0.0.5.lex ADD https://ext.lucee.org/lucee.image.extension-2.0.0.26-RC.lex /opt/lucee/server/lucee-server/deploy/lucee.image.extension-2.0.0.26-RC.lex ADD https://ext.lucee.org/compress-extension-1.0.0.15.lex /opt/lucee/server/lucee-server/deploy/compress-extension-1.0.0.15.lex ADD https://ext.lucee.org/pdf-extension-1.2.0.10.lex /opt/lucee/server/lucee-server/deploy/pdf-extension-1.2.0.10.lex ADD https://ext.lucee.org/org.postgresql.jdbc-42.6.0.lex /opt/lucee/server/lucee-server/deploy/org.postgresql.jdbc-42.6.0.lex ADD https://ext.lucee.org/org.lucee.mssql-12.2.0.jre11.lex /opt/lucee/server/lucee-server/deploy/org.lucee.mssql-12.2.0.jre11.lex COPY lex/cfspreadsheet-extension-3.0.3.lex /opt/lucee/server/lucee-server/deploy/cfspreadsheet-extension-3.0.3.lex Second question: Where can I find the cfspreadsheet.lex URL?

I've only had varying success breaking that ENV line up across multiple lines.... I think some parsers saw the new-lines and messed things up?

Same results when I was playing around with how to dynamically install the extensions that I wanted. It had to be one line, I swapped to having the extensions that I wanted in my app in a directory in GIT. Then in the batch file I use to load my containers (That is in an OS command rather than a "docker" command) I post copy them into the DEPLOY folder as the last line of the batch / script file. (Oh and of course I have my start-up scripts in GIT, too! I use the same scripts for every environment (Local Dev / Staging / Production POPs) And control the bits that might be different by environemnt variable overrides. AND... My .config.json and my server.json are in GIT too - and they also exactly the same file for every environment : again using environment variables for anything that is environment specific. Makes the deployment of EVERY environment, EVERY single time, EXACTLY the same. It is soooo awesome to have that level of confidence in your infrastructure. And troubleshooting (Why does it work on my local box - and not XXX) - becomes either DB data difference or an environment variable difference. (Outside of XXX behaves differently on my local Windows machine to my staging / prod box in Linux) : It simply can't be anything else.

Thanks for your help, I will try to change my command into one line and see what happens. Not sure which way is better, to use the ENV variable, to use ADD extension URL or to download all lex files and copy them from a local directory into the image.

In theory, using the ENV properties saves you in case the URLs or lex files change.

But - if you don't "pin" the version - you're now susceptible to an extension change - affecting your code in unknown ways. And if you're going to pin your extension versions - does it matter if you "hand" provide them - or download them? It isn't as if the extensions are ridiculously sized - that it makes a "marked" difference to your image - if you include them "in" your image. I have my extensions in GIT - so I always know which ones I am using and what version that are - there is no dynamic "play" at hand. And I am NOT a docker guru - so there may be a better "docker" approach. But I have my extensions being copied from the local repository location - into the containers "deploy" folder as the last step of the start-up script.

@gavinbaumanis -- If you use the ENV method, you have to pin the version. The only difference between that and what Harry did above is that he is pointing to the URLs directly (which could change -- don't see it happening, but it's possible), and the ENV just points to the lookup server to look up the extension UUID and version. Doing it your way of copying down the lex files and manually stuffing them into your container using the build process is fine too. It potentially has a few additional moving parts, but they are pretty easy.

I am always happy to learn... But I had thought that the "version" tag (if you like) - wasn't mandatory. And so you "just" got the latest - if you didn't have the version tag (Which was my concern... Oh and the "problem" of needing to allow exceptions in firewall rules etc) That my local copy version side-steps.

Certainly firewall issues and closed environments can be an issue during the build process. On my more secure servers, I do allow northbound connections from the docker builder, but we don't always allow it on our production servers. That can be fixed by running the "prewarm.sh" command on the image build process to have it download and install the plugins.