Using Redis with Lucee: An Approach with the CommandBox Docker Image and Ortus Redis Extension

Well, the title feels a bit like word soup, but I think it’s accurate. When I got started with Lucee, containers, and external cache providers, I blogged about using Memcached. At work, we’ve since shifted our stack, and now primarily use Redis for caching.

This post outlines some reasons for that change and includes an example repo of the Lucee/Redis configuration discussed - which is to say, it is divided into two parts, why and how, and if you’re only here for the code, here’s a link to the repo: mjclemente/redis-lucee-extension

A disclaimer - I’m discussing one method of containerizing a ColdFusion application with external session storage - there are a number of ways this can be done, and dozens considerations when determining the best approach for your particular application.

Why Redis?

There were a handful of factors that motivated us to switch to Redis for most of our external application caches. In no particular order:

Our line of thought might not make sense for your applicaton or situation. But, if you’re interested in taking Lucee for a spin with the Ortus Redis extension, read on.

How to Use Redis with Lucee

Rather than simply listing and describing the steps here, I’ve put together an example Github repo: mjclemente/redis-lucee-extension

The instructions in the README should be sufficient for starting a Lucee container that uses Redis for the session and object cache, via the Ortus Redis Extension. If that sounds interesting, you should take it for a spin!

For those interested in the details, here’s a little more information on what’s going on with this particular approach. We’ll start with the Dockerfile, located here: /build/cfml/Dockerfile

# Starts from the CommandBox Docker Image
FROM ortussolutions/commandbox:4.8.0

# Declared as ENV for clarity
ENV CONFIG_DIR /config

# Copy in our build / config file(s). 
COPY ./build/cfml/config/ ${CONFIG_DIR}/

The config files that are copied in include the Ortus Redis Extension: /build/cfml/config/extensions/ortus-redis-cache-*.*.*.lex. This will be loaded and deployed when we warm up the server.

Our application files are copied in next:

COPY ./app ${APP_DIR}

This is important, as the /app folder also includes the CommandBox configuration files:

Our Dockerfile then installs the box.json dependencies:

WORKDIR $APP_DIR
RUN box install

The only dependency in this particular box.json is the docker-lex-install CommandBox module, which will install the extensions we copied in, later in the build process.

We’ve accounted for the Ortus Redis Extension, but not its license. We do that next, first ensuring that the necessary folders exist, and then moving in the trial license for the Ortus Redis Extension:

WORKDIR $CONFIG_DIR
RUN mkdir -p /root/serverHome/WEB-INF/lucee-server/context/context/ortus/redis/ && \
  mv ortus.redis.license.properties /root/serverHome/WEB-INF/lucee-server/context/context/ortus/redis/license.properties && \
  touch .trial && \
  mv .trial /root/serverHome/WEB-INF/lucee-server/context/context/ortus/redis/.trial

We now have all the components where they need to be, and are ready to warm up the server:

RUN ${BUILD_DIR}/util/warmup-server.sh

During this process, the server is started for the first time, using the version of Lucee defined in server.json.

That’s the end of the build process. When the Lucee/CommandBox image is actually run, the Ortus Redis Extension is installed and the caches are configured, so the “app” is ready to use, with all of its caching stored in Redis.

If you’ve got any questions about this approach, let me know!


  1. You can use TablePlus for free (but there are a limitations). It also supports a wide range of relational and NoSQL databases. I’ve found it a fantastic tool. 

  2. In the case of Github stars, Redis has 39.6K while Memcached has 9.5K. On Docker Hub, there are 7.5K stars for the Redis Image, with 1.4K for the Memcached Image