Luis Majano

January 17, 2019

Spread the word

Share your thoughts

Today we are very excited to bring you the release of our latest Docker container for ContentBox v4.2.1. This is a major re-work of our container images as we now support over 5 different variations of our images, from warmed up servers to alpine versions of ContentBox. We have also added tons of new optimizations and environment variables to control container deployments. Ultimately, we have also updated our images to leverage the latest CommandBox 4.5.0 image!

Learn more about ContentBox at and more about Docker deployment here:

Release Notes


  • Disabled directory browsing for security
  • Added docker hostname to Application name in Application.cfc
  • Added a rolling file appender for all app logs to go to > /var/log/contentbox.log
  • Upgrade to latest CommandBox v4.5.0
  • Updated healthchecks to permit load up times and consistency
  • No runtime flags where ever being used, revamped it to warmup the server correctly and leverage environment variables for execution
  • Removed support for lucee 4.5
  • BE env variable was never working so you can test bleeding edge versions of ContentBox


We have our tags divided by either production or bleeding edge container images. Please choose wisely 💪

Production Tags

The following tags are based off our master branch and are production-ready images. The version number matches the release of ContentBox

  • :latest, :4.2.1 - Latest stable version of ContentBox = 4.2.1
  • :alpine-{version} - Latest stable version based off Alpine Linux
  • :lucee5-{version} - Latest stable version of this image with Lucee 5 warmed up
  • :adobe2018-{version} - Latest stable version of this image with Adobe 2018 warmed up
  • :adobe2016-{version} - Latest stable version of this image with Adobe 2016 warmed up
  • :adobe11-{version} - Latest stable version of this image with Adobe 11 warmed up

Development Tags

The following tags are based off our development branch. These are bleeding edge container images that we use for testing until they are promoted to production tags.

  • :snapshot - Development version of this image (Not of ContentBox, for ContentBox BE use the environment variable BE.)
  • :alpine-snapshot - Development version of this image based on Alpine Linux
  • :lucee5-snapshot - Development version of this image with Lucee 5 warmed up
  • :adobe2018-snapshot - Development version of this image with Adobe 2018 warmed up
  • :adobe2016-snapshot - Development version of this image with Adobe 2016 warmed up
  • :adobe11-snapshot - Development version of this image with Adobe 11 warmed up

Tip: Look in the tags section for other specific ContentBox versions

CommandBox Image Features

The ContentBox image is based on the CommandBox Image, so all features and environment variables are applicable. Please refer to that documentation as well:


This section assumes you are using the Official Docker Image

To deploy a new application, first pull the image (defaults to the latest tag):

docker pull ortussolutions/contentbox

The image is packaged with a self-contained EXPRESS version, which uses a very fast and portable in-memory H2 database engine. To get started just run:

docker run -p 8080:8080 \
	-e EXPRESS=true \
	-e INSTALL=true \

Tip: The INSTALL flag tells the image to take you through the ContentBox installer to pre-seed a database. You can remove this flag once your database is seeded.

A new container will be spun up from the image and, upon opening your browser to http://[docker machine ip]:8080, you will be directed to configure your ContentBox installation wizard.

Persisting Data Between Restarts

The above run command produces an image which is self-contained, and would be destroyed when the container is stopped. If we wanted to run a version in production, we would need to persist, at the very minimum, the database and your custom assets (widgets, modules, themes and media library). In order to do this we need to mount those resources in to the Docker host file system.

By convention, the express H2 database is stored at /data/contentbox/db inside the container. In addition, the custom content module which contains your custom themes, widgets, modules and media library are stored under /app/modules_app/contentbox-custom.

Mountable Points

Mount PointDescription
/data/contentbox/dbThe express H2 database
/app/modules_app/contentbox-customThe custom code module
/app/includes/shared/media**The legacy media location, use the custom modules location instead.

Let's mount both of those volume points, so that our database and user assets persists between restarts:

docker run -p 8080:8080 \
-e EXPRESS=true \
-e INSTALL=true \
-v `pwd`/contentbox-db:/data/contentbox/db \
-v `pwd`/contentbox-custom:/app/modules_app/contentbox-custom \

Now, once our image is up, we can walk through the initial configuration. Once configuration is complete, simply stop the container and then start it without the environment variable INSTALL in place. The H2 database and uploads will be persisted and the installer will be removed automatically on container start.

docker run -p 8080:8080 \
-e EXPRESS=true \
-v `pwd`/contentbox-db:/data/contentbox/db \
-v `pwd`/contentbox-custom:/app/modules_app/contentbox-custom \

INSTALL Setting Caveats

Please remember that the INSTALL environment variable is ONLY used to go through the ContentBox installer wizard. Once the database is seeded with the installation process, you will no longer use it unless you want to reconfigure the installation.

Custom Database Configuration

If you would like to connect your container to an external database system, you can very easily do so, which would allow us to connect from multiple containers in a distributed fashion (MySQL, Oracle, MSSQL, etc). If not, you run the risk of file locks if multiple container replicas are sharing the same H2 database.

Tip: We would suggest you use the H2 database or EXPRESS edition when using only 1 replica.

The image is configured to allow all ORM-supported JDBC drivers to be configured by specifying the environment variables to connect. Alternately, you may specify a CFCONFIG environment variable which points to file containing your engine configuration, including datasources.

By convention, the datasource name expected is simply named contentbox.

To programatically configure the database on container start, environment variables which represent your datasource configuration should be provided. There are two patterns supported:

  1. DB_DRIVER configuration - which may be used for Adobe Coldfusion servers
  2. DB_CLASS configuration - which configures a datasource by JDBC driver and connection string (Both Adobe and Lucee)

An example container run command, configuring a MySQL database would be executed like so:

docker run -p 8080:8080 \
-e 'INSTALL=true' \
-e "DB_CONNECTION_STRING=jdbc:mysql: //mysqlhost:3306/contentbox_docker?useUnicode=true&characterEncoding=UTF-8&useLegacyDatetimeCode=true" \
-e '' \
-e 'DB_USER=contentbox_user' \
-e 'DB_PASSWORD=myS3cur3P455' \
-v `pwd`/contentbox-custom:/app/modules_app/contentbox-custom \

To use the DB_DRIVER syntax for Adobe Coldfusion, an example run command would be:

docker run -p 8080:8080 \
-e 'CFENGINE=adobe@11' \
-e 'INSTALL=true' \
-e 'DB_DRIVER=MSSQLServer' \
-e 'DB_HOST=sqlserver_host' \
-e 'DB_PORT=1433' \
-e 'DB_NAME=contentbox_docker' \
-e 'DB_USER=sa' \
-e 'DB_PASSWORD=myS3cur3P455' \
-v `pwd`/contentbox-custom:/app/modules_app/contentbox-custom \

As you can see, these commands can become quite long. As such, using Docker Compose or CFConfig may provide a more manageable alternative.

Granular Environmental Control

A number of environment variables, specific to the ContentBox image, are availabe for use. They include:

  • EXPRESS=true - Uses an H2, in-memory database. Useful for very small sites or for testing the image. See
  • INSTALL=true (alias: INSTALLER) - Adds the installer module at runtime, to assist in configuring your installation. You would omit this from your run command, once your database has been configured
  • BE=true - Uses the bleeding edge snapshot of the ContentBox CMS, else we will defer to the latest stable version of ContentBox.
  • HEALTHCHECK_URI - Specifies the URI endpoint for container health checks. By default, this is set${Setting: PORT not found}/ at 1 minute intervals with 5 retries and a timeout of 30s
  • FWREINIT_PW - Allows you to specify the reinit password for the ColdBox framework
  • SESSION_STORAGE - Allows the customization of session storage. Allows any valid this.sessionStorage value, available in Application.cfc. By default it will use the JDBC connection to store your sessions in your database of choice.
  • DISTRIBUTED_CACHE - Allows you to specify a CacheBox cache region for distributing ContentBox content, flash messages, cache storage, RSS feeds, sitemaps and settings. There are only three cache regions defined in this image: default, template and jdbc. jdbc is the default cache that will distribute your data, default and template are in-memory caches. Please see the distributed caching section below to see how to register more caches.
  • H2_DIR - Allows you to specify a custom directory path for your H2 database. By convention, this is set to /data/contentbox/db within the container
  • contentbox_default_* - All Contentbox "Geek Settings" may be provided as environment variables, allowing granular control of your ContentBox settings.
  • ORM_SECONDARY_CACHE - If true it will activate the ORM secondary cash to the ehcache provider. By default it is turned off.
  • ORM_DIALECT - You can choose the specific ORM dialect if needed, if not we will try to auto-detect it for you.
  • REMOVE_CBADMIN=false - If true then this image will not publish an Admin module, just the core, REST and UI modules.
  • JVM_HEAPSIZE=512 - The amount in megabytes to assign the JVM running ContentBox. We default it to 512mb.

In addition, the CommandBox docker image environment variables are also available to use in your container. For additional information on using the CommandBox docker image, see the initial release blog entry.

Automatic Session Distribution

By default, the ContentBox image will use the Lucee Open Source CFML engine for running the application. It will also configure the datasource to store user sessions so you can easily scale the image or send it to Docker Swarm, Kubernetes, etc for scalability.

You can also use the SESSION_STORAGE environment variable to switch the connection to any backend you like.

Distributed Caching

By default, our image configures a jdbc CacheBox cache region that will be used to distribute settings, sessions, flash data, content, RSS feeds, sitemaps, etc. This means that out-of-the-box, your ContentBox containers can use the database to distribute its content within a swarm or set of services. However, if you would like to use your own CacheBox providers or a more sophisticated distributed cache like Redis or Couchbase, you can.

We have also prepared a docker compose and distribution example using Redis (more caches to come) and the ContentBox image. This example will allow you to have a stack that can easily distribute your sessions and content via Redis. You can find the repository in this repo under the folder: distributed-example


The image contains built-in capabilities for healthchecks for the running application. You can customize the URL entry point by using the HEALTHCHECK_URI environment variable. By default, this is set${Setting: PORT not found}/ at 1 minute intervals with 5 retries and a timeout of 30s.

Add Your Comment

Recent Entries

CommandBox 5.4.2 Released!

CommandBox 5.4.2 Released!

There is a new update for CommandBox CLI available.  Version 5.4.2 is a patch update that contains a few bug fixes including two important ones. 

  • There is a fix for a regression introduced in 5.4.0 where updating the version of a CF engine doesn't work without forgetting the server first. 
  • There is also an important security impro...

Brad Wood
Brad Wood
October 07, 2021
ContentBox v5.x Released

ContentBox v5.x Released

We are incredibly excited to announce the release of the ContentBox Modular CMS v5 series. This has been a work over 1 year with a complete refocus and rearchitecturing of the core to take ContentBox to the next 10 years. It is also great to note that we are Professional Open Source, FREE, FOREVER. This series includes tons of great features and updates that will take your content management to the next level. From multi-site support, a companion CLI, to a complete Headless CMS deployment, your will be able to deliver your projects in no time. We have also refreshed the official ContentBox site: which is also running 5.

Here is our what's new guide with our full release notes:

Luis Majano
Luis Majano
September 29, 2021
Adobe to Sponsor Into the Box 2021!

Adobe to Sponsor Into the Box 2021!

It is with great honor that we announce Adobe’s support as a Gold Sponsor for this year’s Into the Box.  Their backing has been key in ensuring the success of our events in both the United States and Latin America. 

Paulina Lainez
Paulina Lainez
September 22, 2021