Lucee Docker on Apple Silicon

is anyone already (successfully) using the Lucee Docker images on Apple Silicon? During summer I tried but I got very frequent crashes with strange Java errors so I returned the MBP M1 back then.
My old MBP (Intel) is now making more and more problems so I need to upgrade and looking for M1 Max.
Back then I heard that folks of ColdBox had successfully “ported” everything Java-related to support Apple Silicon but our stack is based on lucee docker images and we don’t want to switch to ColdBox. So, is this already working?

Thanks a lot

Hey Fritz
Which images specifically are you referring to? I have been working on our app images and I get them building for arm64 (Apple M1) as well as amd64 (the usual)
The command is something like:
docker buildx build --platform linux/amd64,linux/arm64 --load -t <imagename> --file Dockerfile .

notice the --platform linux/amd64,linux/arm64

The maintainers or, if it comes from a repo, you, can do your multiple platform building as above.

More information: Leverage multi-CPU architecture support | Docker Documentation

Hi Mark,
thanks for your answer.
Honestly until now I’m referring to images just in my Dockerfile like:

FROM lucee/lucee:

Same Dockerfile used on dev machines up to production servers.
How would I solve this so that the dev machine uses an arm build and the production machine amd?

There are a couple of solutions I can think of:

  1. Ask @justincarter to update the builds an images so they are multi-arch :slight_smile:
  2. For your local builds, you can build the image yourself from the repo: GitHub - lucee/lucee-dockerfiles: Official Lucee Dockerfiles for Docker Hub build images , although I need to figure out how it does the build script.
    The main part would be doing something like docker build --platform linux/arm64 -t ucee/lucee: in that repo but there are loads of --build-args that I am sure @justincarter can clarify.

This would build an image locally that other images could extend. I would look more into it but a bit pressed for time today :frowning:

1 Like

thanks, @markdrew!


1 Like

There is a whole matrix of images they can run and to make multi-platofmr images they need to swap over to using docker buildx which is slightly different

A few months ago I started to add multi-arch build support but switching Travis CI to use buildx was throwing up a few road blocks at the time. I think that’s ironed out but there’s a final issue where the ARM64 builds fail to run the when building in Travis CI, and I hadn’t worked out why and had no way to debug locally.

Since then I’ve got a Mac Mini M1 that I’ll be able to test with but I haven’t had a chance to revisit it just yet. For now everything is sitting in the multi-arch branch, but you don’t need to use that, you should be able to use master just fine.

If you’d like to try a local build on your machine the easiest way is probably using docker build and specifying all the build-args as @markdrew mentioned (for Travis CI the is used but that’s more complex because it requires a bunch of environment variables to be set, and would currently use buildx)

  1. Clone
  2. From the root of the repo run;
    docker build --platform linux/arm64 -t lucee/lucee: . --build-arg TOMCAT_VERSION=9.0 --build-arg TOMCAT_JAVA_VERSION=jdk11-openjdk --build-arg TOMCAT_BASE_IMAGE= --build-arg LUCEE_MINOR=5.3 --build-arg LUCEE_SERVER= --build-arg LUCEE_VARIANTS= --build-arg LUCEE_VERSION= --build-arg LUCEE_JAR_URL=
    (You might be able to omit the --platform argument but I haven’t tried it)

To explain all those build-args, they come from the matrix that you can see in the .travis.yml and would normally be used to produce multiple different images when run via the script, but for your case you don’t need any of that complexity so I think the above command and args should work for the single image that you want to produce.

If you do have any issue with the during your build (e.g. the build output says “Tomcat started.” and then the build times out), you can try commenting out that line in the Dockerfile.

I hope that helps you for the short term, please let us know how you go :slight_smile:


These are the build args I was trying to piece together but run out of time :slight_smile: Thanks @justincarter !!!

1 Like

Hi @justincarter and @markdrew
thanks a lot for your comprehensive help! As soon as my new MBP with M1 Max arrives, I’ll give it try and report back!

Thanks a lot,


For what it’s worth, we switched from the “official” Lucee images to the Commandbox Docker images in order to gain Apple Silicon support, and it went fairly smoothly for us.


When I run the build it starts up and throw this error

03-Dec-2021 06:50:15.898 SEVERE [main] org.apache.catalina.core.StandardContext.loadOnStartup Servlet [CFMLServlet] in web application threw load() exception
java.lang.ClassNotFoundException: lucee.loader.servlet.CFMLServlet
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(
at org.apache.catalina.core.DefaultInstanceManager.loadClass(
at org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(

Which I “think” is related to this issue:

Is there something, I’m missing or does this still not work until the JNA package is updated?

I’m on the Apple M1 Pro, I wonder if that could be somehow different to the M1?

ps. I initially posted this on the wrong thread.

1 Like

I just got around to trying this and I was getting the same exceptions; it’s because I missed a build arg above, sorry! The lucee.jar didn’t download because LUCEE_JAR_URL was missing, so Tomcat had no servlets to start up.

I can run this build and it will complete (including the;

docker build --platform linux/arm64 -t lucee/lucee: . \
--build-arg TOMCAT_VERSION=9.0 \
--build-arg TOMCAT_JAVA_VERSION=jdk11-openjdk \
--build-arg TOMCAT_BASE_IMAGE= \
--build-arg LUCEE_MINOR=5.3 \
--build-arg LUCEE_SERVER= \
--build-arg LUCEE_VARIANTS= \
--build-arg LUCEE_VERSION= \
--build-arg LUCEE_JAR_URL=

Then run the container using the newly created image ID;

docker run -p 8888:8888 fab8b1a426bd

This should work for anyone who needs to build and tag image locally. Hopefully it’ll also get me a step closer to getting the automated multi-arch builds up :upside_down_face:


Hi all,
today finallay I received the MBP M1Max and I used the explanation from @justincarter – worked like a charm! Big thanks!


one more question: I thought everything worked but I’m a bit struggling now with the following docker concept issue:
when I do the docker build steps as @justincarter says and the for this created image the docker run, everythings works.
How can I integrate the image now in my docker-compose file?
When deploying to production environments, I’d like to use the respective platform images as they build there but for my local dev env, I want to use the arm64.
I thought, if I build it locally and the just but the FROM lucee/lucee: to the very exact version, docker locally would find the image and use it. But it didn’t. At least when I start my container (from the docker-compose), it should architecture as amd64 and it is not working.
Could you please quickly point me to the right direction on how to use the arm64 image locally during development in a way I can integrate it into the docker-compose stack?

One thing to add: my bad that it took the amd64 image: I did a docker system prune -a today to fix other stuff. Then, after building my image from the docker-compose, it was not aware of the locally built image. This is resolved now and lucee is running fine.
Anyway it would be great to be able to have this created automatically locally, e.g. by providing arm64 image in general.

1 Like