Is Using CommandBox to run Adobe ColdFusion sites safe in production

[bdw429s]

There were some excellent questions asked on CFML Slack today, and I wanted to get the answers to them out on our community forum where they could benefit the larger community (and Google). In a nutshell, these were the concerns:

1. When I’m using CommandBox, am I really using “Adobe ColdFusion” or am I getting a “copy” of Adobe ColdFusion from the Ortus site?
2. We have an Adobe Support Contract and will Adobe provide support for my CommandBox installation?
3. CommandBox is not using Tomcat, but JBoss Undertow. Will it be capable of managing the load of a production site?

These are great questions, and one any Enterprise would want answered before committing to CommandBox. Let’s go through them categorically. (some of these responses culled from @jclausen’s Slack replies as well)

When I’m using CommandBox, am I really using “Adobe ColdFusion” or am I getting a “copy” of Adobe ColdFusion from the Ortus site?

CommandBox is just a CLI orchestration tool. You can run any CFML server product you wish to including old Blue Dragon servers! You are getting the officially distributed J2EE deployment of Adobe ColdFusion - just packaged to run on CommandBox.

The WAR packages you start with CommandBox are literally the WAR deployment as Adobe ships it with their official updaters applied. Do don’t modify them outside of that so it’s not a “copy”, it is an actual Adobe WAR deploy. We host the CommandBox-packaged artifacts with Adobe’s permission on S3 for high-availability.

We have an Adobe Support Contract and will Adobe provide support for my CommandBox installation?

A J2E deployment is a valid and supported method of deploying Adobe ColdFusion, and by “supported”, we mean supported by Adobe themselves. We have many clients with ACF deployed on CommandBox for production sites and they get regular normal support from Adobe for matters related to the ACF engine and we support them for matters related to the servlet (CommandBox). Some of these customers have paid Adobe support plans which are fully honored by Adobe. Note: to run Adobe J2EE deployments in production requires an Enterprise license (per Adobe).

It’s also worth pointing out that CommandBox itself is professional open source and fully supported by Ortus Solution via our Ortus support plans, so you can get support, training, fixes, and even deployment help for your production servers as many of our clients already do.

CommandBox is not using Tomcat, but JBoss Undertow. Will it be capable of managing the load of a production site?

Absolutely, yes. There are thousands of instances of CFML apps using CommandBox to run them in production. We’ve found JBoss Undertow to be far superior and more efficient than Tomcat. As far as Undertow performance-- it has a lot more feathers in its cap than our existing users. Undertow is a professionally supported product of RedHat/JBoss and is used to power their Enterprise-level Wildfly server, which is the core of their JBoss EAP (Enterprise Application Platform) which is deployed all over the internet, supported by one of the largest names in Java software today

Undertow is incredibly capable and blazing fast. We’ve actually done head-to-head tests with Undertow, comparing it’s serving of static files to Apache and IIS and it matched their throughput exactly. Furthermore, we added CFML (both Adobe and Lucee) to the TechEmpower framework benchmarks which includes basically every language/platform/framework ever written in a side by side automated performance test. We powered the CF engines using our Ortus Docker container, running CommandBox/Undertow, and CFML performed amazing, performing faster than Node, Groovy, Ruby on Rails, Laravel PHP, and Django Python in some tests.

How does CFML really perform compared to other languages?

I’ve talked about the TechEmpower performance benchmarks before, but I wanted to highlight them again. They are the closest thing the internet has to a giant cage match between nearly every language and framework out there. The benchmarks have a suite of tests, such as run 20 queries on a page and output some data, and every language and framework implements the same logic in their syntax and style. The tests literally take days to run in full and spin up each combination of language and fram…

All this was on a CommandBox/Undertow-powered web server, so there is no concern about performance or quality of that RedHat-powered servlet container.

---

Hopefully this help answer those questions for people looking to dive into the CommandBox ecosystem for deploying servers, which includes great open source tooling that makes configuring, monitoring, and updating your servers faster and easier.

[FMancardiGmail]

Brad, thanks a lot for this post.

[GavinBaumanis]

From a user’s perspective,

When I first came across commandbox - I thought it was just for development.
I thought it was a developer-friendly “launcher”…
Additionally, all the posts about using cfconfig also bothered me.
I was worried about security and using it in Production.

But after some discussions / reading forum posts etc - it becomes really evident - that using cfconfig / commandbox doesn’t add any risk. You still have the same risk - about "Where do I store the “sensitive” values…

And the ease at which you can export configs and (separately) script configs as part of builds with cfconfig / commandbox - IMHO makes server administration and securing it - much more easier and more visible. For it is now part of a peer-reviewed pipeline of work - as opposed to a user-centric task of editing settings via the admin webApp and we all know - that humans make mistakes,. all the time!

[FMancardiGmail]

This informations is the result of questions/answers chat in https://cfml.slack.com/ with Brad Woods

Q1 - What is the place of Runwar in the whole CommandBox Architecture?
Honestly, there are a few moving parts and the difference is largely moot.

• CommandBox is the CLI (written and maintained by Ortus) for orchestrating deployments
• Runwar is a Java tool written by Denny Valiant and now maintained by Ortus which encapsulates servers started by the CLI
• Runwar embeds Undertow, which is a service layer for creating servlet deployments.
• Undertow provides both the web server and servlet container

So Runwar would be more/less the equivalent to Tomcat and Undertow would be more/less the equivalent to Catalina
We’ve packaged them all together so you really just need ot know about “server start” and we take care of the rest

The J2E stuff happening under the covers of ColdFusion is a black box to most CF users who don’t even
understand the demarcations between Tomcat/Catalina/ColdFusion
so I don’t generally bother documenting the stuff under the covers of CommandBox, though I’m happy to explain it!

And FWIW, CommandBox does not use WildFly directly.
We use Undertow directly.
Wildfly is more of an equiv to Tomcat.
Undertow is just a service layer in a collection of jars which you embed into an app of your own.

Q2 - why do you do not use Wildfly directly?.
Because we could not create the deep level of integration that we get using an off-the-shelf servlet engine.
With any out-of-the box servlet, you are stuck with
- their installation
- their bootstrapping
- their config files
- their web.xml parsing
- their settings/config/xml files
Undertow gives us all the power of WIldfly, but in our own packaging which is custom built for CF engines,
the way we need it to work:

• we control how its bootstrapped
• We control how the deployments are made
• we control the web.xml parsing which enables many CF-specific behaviors as well as overrides
• we control the custom resource manager (which Adobe also does in their custom build of Tomcat)
• we control the config files to be our server.json
• we integrate things like the tray icon
• we can support our own env var conventions
• we can add in our custom server rules for CF-specific lock downs and rewrites

There is basically a TON of customizations we’re able to do by using all the features Undertow provides,
but packing it in our own Java app which decides what pieces to wire up

Undertow is like a giant box of legos.
It has handlers for everything imaginable–
client cert auth, predicate language, header management, proxy headers, etc.
We get to build up the pieces that make the most sense for a CF application and
tie it all to our config files very tightly

Runwar is the Java app which spins up Undertow and ties all the pieces together
to create the actual server deployments.
You basically can’t use undertow by itself, it’s just a pile of jars that sit there.
You have to compile Java code of your creation to actually use undertow.
And that is where runwar comes in.

This is what gives us the power to have CLI settings like
server set web.blockCFAdmin=true
and we automatically plug in the plumbing to secure your CF and Lucee admins.
We have this power and capability because we control the entire stack from the ground up

Lucee doesn’t have that power as they bundle stock tomcat and depend on its config.
Adobe technically could do stuff like that as they have a custom forked build of Tomcat,
but they don’t have the creative foresight to build those sort of features in and
they basically just use Tomcat as-is with a custom resource manager
to create the behavior that ModCFML mimics

This is why Ortus is ahead of the curve and has been for years on the most flexible and
powerful way to deploy CF apps with a plugable architecture for
the entire web server config
rewrites
fusion reactor integration
CFConfig integration
dotenv integration
packaged deployments
full env var support for every configurable item of the server and CF config
Adobe and Lucee don’t come close to any of this and it’s because they’re just using an off-the-shelf
servlet solution which is not created from the ground up with CF deploys in mind.

[Eggely]

Does anybody have any experience of using CommandBox/Coldbox with a hosted coldfusion solution?

Hostek can supply the CF enterprise licence for J2EE installations on windows, but I was just wondering if there are any companies more specialized in ColdBox.