A language runtime, rewritten once
CFML is still being written, still being maintained, and until recently had only JVM runtimes to run on. RustCFML is an attempt at the other option: the same language, a native binary, and documentation that says where it does not work.
It began as a question about models
RustCFML started as a proof of how capable AI models had become, begun by Alex Skinner. The engine has been written almost entirely by AI, predominantly Claude Opus, with research and test synthesis assisted by local models.
Rust was not an arbitrary choice of host language. Its compiler rejects unsound code immediately and specifically, which is what makes it a good substrate for AI-assisted work: a stochastic generator becomes something that converges, because every wrong turn comes back as an error a model can act on. CFML sits at the other end of the same idea: a powerful, forgiving language with one obvious way to do most things, which is why models emit it correctly and why people learn it quickly.
There is a test suite that has to pass against Lucee, a compatibility target published in cfdocs, a licence that is genuinely permissive, and a written account of everything that does not work yet.
// CFML source, all the way down to native code.
.cfm / .cfc
→ tag preprocessor
→ CFScript
→ lexer
→ parser
→ AST
→ compiler
→ bytecode
→ VM ( bytecode cached per template )
// A Cargo workspace of focused crates:
cfml-common cfml-compiler cfml-codegen
cfml-vm cfml-stdlib cli
cfml-qoq wasmFive opinions, held deliberately
These are the reasons the engine is smaller than you might expect.
A lean, stable core
Nothing gets added to the core that doesn't belong or is prone to constant churn in the wider ecosystem. Think of it as an LTS-style engine: reliability first, and already fast enough that speed is not the constraint.
Libraries over built-ins
Where a capability is better served by a library, it stays out of the core. What the engine does is make sure it is compatible enough to run those libraries.
No administrator, ever
There is no web console and there never will be. Configuration is a file, .cfconfig.json, with environment-variable substitution for secrets, so your settings live in version control and your deploy pipeline.
Inspired by real apps
Features are driven by applications people are trying to run, and by modern deployment practice.
Honest about Java
There is no JVM under the hood, so the classes applications actually reach for are hand-written shims instead: over a hundred of them, across java.lang, java.util, java.util.concurrent, java.security, java.text and java.time, plus the third-party libraries frameworks depend on. Enough that CFWheels and Preside run without application changes. They are emulations rather than the JDK, though: the goal is to run the libraries, not to reimplement Java. Every gap is written down.
Compatible, verifiably
The target is cfdocs.org with Lucee as the reference implementation, and a suite that runs against both. Compatibility is something the project checks, not something it claims.
Where the speed comes from
A preprocessor, a compiler and a bytecode VM: the same shape every serious language runtime has, minus the host virtual machine underneath it.
Shared ground
The types, scopes and utilities every other crate needs, so the parser and the VM never disagree about what a query is.
Front end
Tag preprocessing, lexing, parsing and AST construction. Fifty-plus tags become CFScript before anything is compiled.
To bytecode
AST to stack-based bytecode, cached per template so an unchanged file is never compiled a second time.
Execution
The interpreter, the component model, threading and the async runtime that serves your requests.
Four hundred functions
The built-in library: strings, dates, JSON, hashing, database, mail, HTTP, spreadsheets and images.
SQL for queries
Query-of-queries on a pure-Rust SQL engine, parallelised with rayon. No JDBC, no embedded Java database.
Deeper, including the memory model and the extension ABI: docs/architecture.md.
The ones that come up every time
Is CFML not a dead language?
No. It is a maintained one. Lucee has carried an open-source engine for over a decade and ships on a current Java baseline; BoxLang added a modern JVM dialect with enterprise adoption in its first year; CFCamp and Into the Box still run every year. What died is the tag-soup reputation: most CFML written today is script, with closures, arrow functions, null coalescing and member methods. RustCFML adds a runtime.
Is this ColdFusion?
No. CFML is the language; ColdFusion is Adobe's implementation of it. RustCFML is an independent, MIT-licensed engine that runs the same markup and script. ColdFusion is a registered trademark of Adobe Inc. and RustCFML is not affiliated with or endorsed by Adobe.
Is there a JVM under the hood?
No. RustCFML is a native binary with its own compiler, bytecode and VM, so it starts instantly, sits at roughly a tenth of the memory of a warmed JVM engine, and compiles to WebAssembly, which is what lets the same templates run on a Cloudflare Worker. Java is handled by shims rather than a JVM: over a hundred classes, enough that frameworks like CFWheels and Preside run unchanged, though they are emulations, so expect differences at the edges.
Will my Lucee application run on it?
Many do, unchanged, including applications on frameworks. CFWheels ships a RustCFML adapter upstream and Preside runs with no application changes, helped by broad Java shims for the classes CFML code reaches into. RustCFML targets cfdocs.org with Lucee as the primary compatibility reference, and every test in the suite runs against both engines. It is not a complete engine, though: no ORM, no SOAP/WSDL, no PDF, no LDAP, and image functions are partial. Check Known Issues before you commit to a migration.
Why is there no administrator?
There never will be. Configuration is file-based through .cfconfig.json, with environment-variable substitution for secrets, so your settings live in version control and your deploy pipeline rather than in a web UI on the server.
Is it production ready?
Yes. It is stable, it is fast, and it runs real applications. The core moves deliberately slowly, aiming to be an LTS-style engine rather than the fastest-moving thing in the ecosystem, and every change has to pass the suite on Lucee as well as here. It is not a complete engine, and the gaps are written down rather than left to be discovered: no ORM, no SOAP/WSDL, no PDF, no LDAP, and image functions are partial. Read Status and Known Issues first, so what is missing is a decision rather than a surprise.
Why write a CFML engine in Rust?
For what Rust gives the engine (a run-anywhere single binary, real OS threads, memory safety in the interpreter itself, and a WebAssembly target) and for what it gives the people writing it. The Rust compiler rejects unsound code immediately and specifically, which is why AI coding agents converge on it, and this engine is largely AI-written. Fast, verifiable code underneath; readable, quick-to-write code on top.
Can I use it from my own Rust project?
Yes. The engine is a Cargo workspace of focused crates and there is a documented embedding path for driving CFML from Rust. You can also extend a stock binary with .rcx native extensions rather than forking the engine.
How is it maintained?
It began as a proof of what AI models could do, written almost entirely by AI with human research and direction, and is maintained as an open-source project under MIT. Pull requests are the preferred contribution route, and the bar is that a test must pass on Lucee.
Read the source, it is only Rust
Everything is in one repository: the interpreter, the documentation, the tests that run against Lucee, and the issue tracker where the hard decisions get made in public.