Lucee: a CFML application server running on the JVM

A dynamic tag and scripting language, not a ColdFusion clone

Lucee is described as a dynamic, Java based, tag and scripting language used for rapid web application development, and the project description calls it a high-performance, open-source CFML server written in Java.

The positioning that matters is the compatibility layer. The README states that Lucee provides a compatibility layer for Adobe ColdFusion and CFML using less resources and delivering better performance. So the audience splits in two. The first group has ColdFusion applications and wants to move off a commercial engine without rewriting templates, tags or scripts. The second group wants the CFML model, with its tag based templates and its scripting style, running on infrastructure they already understand.

The engine layer sits on components that a Java team would pick anyway. The README names web services through REST, SOAP and HTTP, ORM via Hibernate, searching via Lucene, datasources including MSSQL, Oracle and MySQL, and caching through Infinispan, ehcache and memcached. That list is the practical argument for the project: it is not a CFML runtime bolted onto a JVM, it is a server that assumes those libraries are the right ones.

The philosophy section states the attitude plainly, saying the Lucee team treats slowness as a bug, and that the team attempts to resolve inconsistencies found in traditional CFML, either by forcing changes in language behaviour or by providing configurable options in the Lucee Administrator.

A servlet, so any container will do

The system requirements section is short and gives away the deployment model. Lucee is a JVM language running as a servlet on just about any servlet container, and the README names Apache Tomcat, Eclipse Jetty, JBoss AS and GlassFish as examples.

That matters for operations. Lucee is not a self contained server binary with its own lifecycle and configuration format; it is a WAR style deployment into a container you already run, with its own administrator interface for configuration. The container handles process management, TLS termination in front of it, and JVM flags.

There is one caveat in the README about that freedom. The project standardises on Apache Tomcat for installers and Docker containers, with the stated reason that there is only so much time in the day. In other words, Jetty, JBoss AS and GlassFish are possible, but the packaged distributions and the Docker images assume Tomcat, so anything else is a path you test yourself.

Official Docker images and Dockerfiles live in a separate repository, lucee/lucee-dockerfiles, and distributions are downloaded from download.lucee.org. The README does not document a container run command, so the image reference and tags are found in that repository rather than here.

LuCLI manages the server and the project from a terminal

LuCLI is a separate command line tool for Lucee development and deployment, hosted at lucli.dev with its source in the cybersonic/LuCLI repository. The README describes it as providing server lifecycle management, CFML script execution, a module system, dependency management and AI integration, all from the terminal.

The install is a one-liner script:

curl -LsSf https://lucli.dev/install.sh | sh
# Windows:
powershell -ExecutionPolicy Bypass -NoProfile -Command "irm https://lucli.dev/install.ps1 | iex"

and it requires Java 17 or newer.

Per project settings live in a `lucee.json` file, and the README gives the shape:

{
  "name": "my-project",
  "lucee": { "version": "6.2.2" },
  "port": 8080,
  "webroot": "./",
  "jvm": { "maxMemory": "512m" },
  "dependencies": {
    "cfwheels": { "type": "cfml", "source": "git", "url": "https://github.com/cfwheels/cfwheels" }
  }
}

The file pins the Lucee version for that project, the port, the webroot, JVM memory, and dependencies resolved automatically from git or Maven. That last part is the significant one: CFML libraries and Lucee extensions are resolved by the tool rather than by hand.

The rest of the feature list is broader than a launcher. There is a module system where reusable CLI modules live in `~/.lucli/modules/`, secrets management that stores and injects encrypted secrets into your Lucee servers, a daemon mode for programmatic background access, and batch files with the `.lucli` extension for running command sequences.

The skill file and the MCP server target AI assistants

Two pieces of the README concern tooling for AI assistants, and they are separate from LuCLI.

The first is a machine-readable skill so an assistant knows modern Lucee, described as drop-in context for Cursor, Copilot, Warp, Claude, ChatGPT and others, and said to be always aligned with the latest docs. It is published at skill.lucee-services.com/main.skill and at docs.lucee.org/lucee.skill.

The second is the Lucee MCP server, hosted by Lucee, which gives an assistant callable tools. The README lists them: `search_lucee_docs` to search functions, tags and recipes in the documentation, `get_lucee_function` for the full descriptor of a built-in function including arguments, types and examples, `get_lucee_tag` for the same for a tag, `parse_cfml_ast` to parse CFML source into an AST covering tags, calls and control flow, and `query_cfml_ast` to query that AST by node type, name or line number.

That last pair is the interesting one for a team, because parsing CFML into an AST is the capability an assistant needs to reason about a codebase rather than guess at it. It also depends on the hosted side. Unlike the LuCLI tool, which you install locally, the MCP server is described as hosted by Lucee, so the assistant integration depends on a service you do not run.

LuCLI's own AI integration is separate and configurable: it can configure LLM endpoints and run AI prompts with skill support, which is a different thing from exposing Lucee's documentation to an assistant.

Building from source means dealing with a large test suite

Source builds are documented separately at docs.lucee.org, and the README gives one practical warning that saves a lot of time. Lucee has a lot of test cases, and there are handy build flags that can be used to avoid running the entire Lucee test suite when you are working on a specific feature, which the README notes applies to Lucee 6 and later.

That is a real signal about the size of the project. The repository layout shows a large codebase: a `core/` directory, a `loader/`, an `ant/` directory for Ant build files, `instrumentation/`, `dev/`, `test/`, plus `build.properties`, `maven-settings.xml` and Eclipse formatter settings such as `eclipse-formatter/` and `org.eclipse.jdt.core.prefs`. The presence of Ant and Maven configuration together suggests a build that has to accommodate both eras of Java tooling.

The test framework is TestBox, with a customised CFML wrapper around it located in the root `test` directory. The suites rely on a range of test services such as S3, database and FTP, and the README points at `_setupTestServices.cfc` in the source to see how those are configured.

For contributors that is fine. For anyone evaluating the project, it is worth knowing that the test suite depends on live external services, so a green local run means credentials and reachable endpoints, not just a passing suite.

Version lines run in parallel, with 8.0 and 9.0 on the horizon

Lucee ships several version lines at once, and the release history shows that in practice. Recent tags include 7.1.1.17 on 2026-10-19, 7.0.6.10 on 2026-10-16 and an alpha, 9.0.0.4-ALPHA, on 2026-10-19, with the last push on 2026-10-20. The default branch of the repository is 7.1.

The README's what is new list names Lucee 7.1, Lucee 7, Lucee 6.2, Lucee 5.3 Kabang and Lucee 5, and adds that Lucee 8.0 is coming soon. The eight series is therefore announced, and a nine series is already producing alpha tags.

The cost of parallel lines is the breaking changes documentation, and the README links three documents: breaking changes between 6.2 and 7.0, between 7.0 and 7.1, and a third between 7.1 and 8.0 marked as coming soon. Every page in the list is also in the documentation guides, and the changelogs are split between per release changelogs and a reference of new tags, functions, arguments and attributes.

That last split is a practical detail for anyone upgrading. A change can be an addition to the language reference rather than a change in behaviour, and the two changelog sites are where you would look. The release approach is described in the README as following what it calls the Tip and Tail Model of Library releases, with the sentence cut off in the version of the README here, so the exact release rules are in the project documentation rather than in the repository.

LGPL-2.1 terms, and the boundary of the CFML world

The licence field on the repository says LGPL-2.1, and the repository carries a `License.txt` file along with a `SECURITY.md` and a `CONTRIBUTING.md`. For a server that people deploy into their own infrastructure, the LGPL arrangement means that changes to Lucee itself must stay open, while applications running on it are your own.

The community framing is explicit in the README, which reminds people that Lucee is a community project, and points to a mailing list and forum at dev.lucee.org for general application developer support and for hacking on Lucee itself, a bug tracker at luceeserver.atlassian.net, and a list of LAS Members who provide commercial support.

The boundary worth being clear about is the language. Lucee is CFML. The repository topics list jvm languages, but the engine implements the CFML tag and scripting model with a ColdFusion compatibility layer, and Java is the host, not an alternative language you write your application in. If your team wants to write the application in Java, Kotlin or Scala and still use Lucee, that is not what this is.

The other limitation follows from the architecture. Running as a servlet means you inherit the servlet container's deployment model, its class loading rules and its upgrade cadence, and the configuration that Lucee itself exposes lives in the Lucee Administrator rather than in the container's configuration. For a team already running Tomcat or Jetty in production that is a comfortable place to land. For a team looking for a single binary to copy onto a server, it is not.

Editorial conclusion

Adopt Lucee when you already write CFML or need to maintain CFML, you can live with a JVM and servlet container in your stack, and you want Hibernate, Lucene and caching without assembling those integrations yourself. Skip it if your team is not on CFML, or if you need languages other than CFML on the same server, because the compatibility layer is the product rather than a side feature. Verify first that the Lucee version you pick matches your CFML code, reading the breaking changes documents between 6.2 and 7.0, and between 7.0 and 7.1, before you upgrade a live application. The licence field on the repository says LGPL-2.1, the default branch is 7.1, and the last push was on 2026-10-20.

Frequently asked questions

Official sources

1. License: LGPL-2.1
2. lucee/Lucee on GitHub
3. Project website
4. README
5. Releases