Lucee/NGINX Docker and custom entrypoint


From lucee/lucee: docker image, which will be deployed both on local developer machines using docker compose, and in Kubernetes as a privately published image.


The Lucee Admin password will vary by ENVIRONMENT. Therefore we need to be able to set an environment variable for LUCEE_PASSWORD, which is NOT part of the build process. Then when the container is spun up from the image, BEFORE Lucee starts, a script (which is copied in during build) is executed that will read the container’s environment variable and echo it into /opt/lucee/server/lucee-server/context/password.txt - after which Lucee will be spun up, read and encrypt the password, and delete the file.


How can I use a Docker entrypoint with the image specified above to do this?

does this blogpost from @markdrew help?

No, because that injects the password file at build time. That would require a separate image for each environment. Kubernetes does not build the image, it takes an existing image, applies environment variables, and spins up the container(s) from it. Therefore, each container must read an environment variable and create the password.txt file when it is spun up.

EDIT: Also, storing the password.txt file in the Docker image is not a good idea.

You need to wrap your existing entrypoint in a script that you change to set the password and call the old entrypoint.

For example if your entrypoint was defined as:

ENTRYPOINT [ "/lucee/" ]
You can create another script called (for example): /lucee/
Which would then do something like:

echo ${LUCEE_PASSWORD} > /lucee/lucee-server/context/password.txt 

And then set your entrypoint in your docker container (last thing) as:
ENTRYPOINT [ "/lucee/" ]

Now when you start up it would set the password on startup. Also since lucee checks for this file it would delete it after it has saved the contents into the lucee-server.xml file.


1 Like

The problem is, the Docker image i referenced above, lucee/lucee: , HAS no entrypoint that I can tell. The Dockerfile has no reference to an entrypoint, nor does the instructions on the Docker page where the image is described.

Check out: lucee-dockerfiles/Dockerfile.nginx at master · lucee/lucee-dockerfiles · GitHub
The command is:
CMD ["supervisord", "-c", "/etc/supervisor/supervisord.conf"]

Or rather supervisord -c /etc/supervisor/supervisord.conf

I would have a play with your own image based off this (which is what I presume you are doing?)

FROM lucee/lucee: 
COPY ./ /lucee/
CMD ['/lucee/']

Just tested this out.

FROM lucee/lucee: 
COPY webroot /var/www
COPY ./ /lucee/
CMD ["/lucee/"]

Then for I have:

echo $LUCEE_PASSWORD > /opt/lucee/server/lucee-server/context/password.txt
supervisord -c /etc/supervisor/supervisord.conf

I build the image:
docker build -t markdrew/lucee_test -f Dockerfile .

I then run the container:

docker run --rm --name lucee_test -p 9898:8888 -e LUCEE_PASSWORD=elvis markdrew/lucee_test

The password is no longer the default password but now through the power of environment variables it’s set to elvis


1 Like

That is perfect. I owe you many a beer.

My vote (if i had one) would be for this functionality to be just baked into future Lucee images as the means to set the Lucee admin password via env vars. It masks the need to create the password.txt file manually and somehow inject it, which (in our case at least) could have lead to a less secure way to do it by baking the password.txt file into the images one creates. But I’ll be the first to admit i’m no expert yet. =)

1 Like

Somewhat related but not - how can i find the latest image that would essentially be:


I’d like to use the “latest release of the light version of Lucee with nginx”, but when i filter tags on


they all appear to be SNAPSHOTs, which I assume are not recommended for production…?

In Lucee terminology - what you think of a SNAPSHOT and what the LUCEE project thinks of as a SNAPSHOT are possibly different.

If you think of SNAPSHOTS as;
The latest Release with PATCHES to address known issues found since the release was published.
You’re on the right track.

So - the use of a SNAPSHOT in Production is not as “scarey” / “flakey” as you might otherwise envisage it to mean.

Of course - create an image with a SNAPSHOT - run YOUR application’s TESTS, prior to you creating your Release - but that’s just goo practice, no matter what libraries and their status, that you include as part of your “stack”.

Hope that helps.

As stated on the lucee download page that involves Lucee snapshots: “Snapshots are generated automatically with every push to the repository. Snapshots can be unstable are NOT recommended for production environments.”

This question has been answered here already

I stand corrected!
Though I am pretty certain - that in another thread there was the advice that the SANAPSHOTS are as I explained them… thus my reply…

1 Like

Yes! I’ve seen that too somewhere. In fact, snapshots can have pure patch fixes. And with the ongoing work of the Lucee core team with the latest added enhaced testings (during builds), they are getting much better and more stable than before.

Thank you both for your input… so then if we’re not to use snapshots for production, I still need to figure this one out:

… without browsing through 64 pages of tags?

isn’t the naming convention for docker images pretty straightforward?

just edit the version number for which ever image you want to use?

I figured it out earlier this morning (once my coffee was in me) after re-reading the naming convention and taking a stab at the stable release version number combined with what I wanted. Ended up at:


And works beautifully.