Configuring Settings Performance/Caching

Different Cache and Performance settings to improve overall performance

We’d like to be able to toggle between Never and Always depending on our deployment environment. Specifically, in a Docker world I want Never on in production and Always on when developing.

This doesn’t appear to be possible at the moment using environment variables but is flagged for implementation as part of the nominated improvements to configuration:

Getting all the options articulated in environment variables I think is going to be hard and probably not all that useful (see below for config screens) – perhaps, why it’s still not implemented.

My assumption is that higher levels, such as Server act as a simple default for the eventual resource mapping, assuming some sort of implicit resource mapping for files not explicitly mapped.

Server -> Web Context -> Resource Mapping

From our perspective, we only need environment variables to nominate defaults at the top level. We don’t need to nominate specific settings at the web context (of which there can be many) or the resource mapping (of which there are many) levels via the environment.

We are quite happy to set specific values (for example for a resource mapping) via code in the Application.cfc.

I’d make the argument that all we really need is a “top level” default set in the ENV variables:

[ENV] → [Server]
[Server] → [Web Context]
[Web Context] → [Resource Mapping]

Using a super simple string like:


For example, you might set this for your development environment via docker-compose.yml like so:

  build: ./5.2
   - "8052:8888"

And enforce Never by default using your Dockerfile:

FROM lucee/lucee52:latest
ENV LUCEE_JAVA_OPTS "-Xms512m -Xmx1024m"

Administrator Screens

Server Settings

Web Context Settings

Resource Mapping Specific Settings


Related to this issue, you cannot programmatically set the Inspect template options in Application.cfc:

// "Inspect Templates (CFM/CFC)"/"Web Accessible" setting not supported with application type mappings

The full web interface

You have to “hack the Gibson across state lines” by setting the values you want in the web interface and then copying the underlying XML files in your Dockerfile. This is almost as painful as Angelina’s role as roller-skating hacker.

Some are probably already aware, but for those who are not, I’d like to add to this that setting the inspect template value (or any admin setting, really) is already possible with the CFConfig project. In fact, the CommandBox-based images have a convention whereby any env variable that starts with “cfconfig_” will automatically get picked up and set for you. So this would work today, even on Lucee 4.5:


Using the CLI directly can apply that setting to the server or the web context as desired. And for completeness, this is how you would use CFConfig to set it on a resource mapping.

cfconfig cfmapping save physical=/foo virtual=C:/foo/bar inspectTemplate=never

While this sounds wonderful, I’d like to see Lucee provide native options for configuring the server without the need for third-party extensions.

I’d like to see Lucee provide native options

Yes, for sure. In the meantime however, I’d personally like to see us stop recommending people copy XML files around. It’s heavy fisted and brittle. It was all we had for years, but not any longer.

The default “Inspect Templates” option is one of the very few remaining Lucee settings that can only be configured via changing the XML file – most of the rest can either be changed via Java system properties or Application.cfc.

+1 for native support in Lucee via the LUCEE_INSPECT_TEMPLATES environment variable :smiley:

1 Like

this is already marked as a urgent feature to add:


@micstriit i notice Inspect Templates is still incomplete. Is there an issue we should be tracking in JIRA that is specific to this feature or is the spreadsheet the best way to keep tracking status of configuration in general?


Hi Guys, on this topic;

Does anyone have an example how to change the template inspection to “Never” via the lucee-server.xml in a Docker environment?

I see 4 mappings with this setting at “once”, do I simple change these to “never” or do I need to create a new one for my webroot?

@ToineKs You may notice this thread covers several methods of configuring several differnt types of Lucee installs. You haven’t provided any information for us to know what sort of docker image you’re using. If you’re using the Ortus CommandBox image, then it’s as simple as setting the following Env var:


Or adding the following to your server’s .cfconfig.json file

  "inspectTemplate" : "never"

We are using the image “lucee/lucee:” and aren’t using cfconfig.

I prefer a solution without cfconfig, thats why I was referring to the lucee-server.xml. Any thoughts?

Yes, change your docker image :slight_smile: I’m not sure why you’d want to use a setup that required you to blindly copy XML files around. That’s the power of the Ortus image. The level of power and easy of use of the Ortus image to do basic things like configure your setting at deploy time, lock down your admin, or dial in exact ACF/Lucee versions is unparalleled. Yes, I’m part of Ortus and a little biased, but it boggles my mind that you’d use anything else :wink:

1 Like

@micstriit was this missed in the config changes? Should we raise a separate JIRA ticket to track this specific configuration?

1 Like

Hello All :slight_smile: Sorry for reviving this topic but I cant find a similar solution for Lucee5 or 6.

We have been POCing with lucee images for a while now but we need to set the inspect templates to Never automatically at build time. The LUCEE_INSPECT_TEMPLATES suggested by @modius is definitely what we are looking for!

I see this is possible with Command Box but this involves introducing a third party ecosystem as a dependency just for one server setting.

If it still can’t be done natively in Lucee without ( the admittedly impressive ) Command Box project can anyone explain how they are working around it in a bit more detail?

Many thanks for any help :smiley:

This could the the answer: I will test it

Yeah finally got round to testing the above. Worked a treat: inspect template now = never in our containers :smiley: