Configuring Lucee server : CFCONFIG Now that you no longer have to deal with Tomcat / NGINX.... You can treat the Lucee server as if you were using a hosting company. And by that I mean you can set all your normal server settings (UTF / timezone / etc) and then "separately" use your Application.cfc for all your "Application" specific settings. (datasources / directory mappings / etc) You don't have to do it like this - I am just demonstrating that if you prefer - you can have separation between "generic" Lucee config items and the settings for your CFML application. Or you can treat the Lucee Server's configuration - as if you were hand-configuring everything within the Lucee Web admin - where the server "generics" and your CFML app's settings are a "joint" effort. In the CommandBox world - there is a SEPARATE tool that you use with CommandBox to do your Lucee Configuration. CFConfig All the guff is here at https://cfconfig.ortusbooks.com/ It used to confuse the heck out of me - because I saw them as the same "thing" (CommandBox and CFConfig) Afterall you MUST have CommandBox to use CFConfig. But you do NOT have to be using CommandBox for your server infrastructure - to use CFConfig. That is you can install Lucee or ACF by a native installer. AND You still CAN use CFConfig to configure your server. But in order to use CFConfig - you MUST install CommandBox. It was again another one of those things that added to my confusion / frustration. But if you think of CFConfig as a stand alone tool that needs dependency "XXX" - then that might help. It is just a coincidence that CommandBox is the dependency you need. It is just a coincidence that you CAN use CommandBox to setup / run your CFML server. For me : Once I truly understood - that they are different tools - for different tasks - it really started to "click" for me. Just like CommandBox - CFConfig has a few ways to do the same task. You CAN store all your Lucee Admin settings in a JSON file. You CAN set all your Lucee Admin settings via environment variables. You can mix and match - which is what I do. I set everything I need (from a Lucee Admin perspective) in the ".cfconfig.json" file. (note the leading "." in the filename) The filename is a convention. If you are using CommandBox for your Lucee Server (not a native installer) Then CommandBox - by convention will look for and use a ".cfconfig.json" file. The file CAN be named anything you like - but if you name it something else - you will need to tell CommandBox what the name of the file is - that you are using for Lucee configuration. The ".cfconfig.json" file CAN be anywhere By convention it is in the APPROOT. If it is somewhere else you need to tell CommandBox where it is. (don't forget though - you CAN use CFConfig - without using CommandBox to also run your CFML / web server.) CFConfig itself has IMPORT and EXPORT abilities. So you certainly can configure everything via the web admin - and then export the "lucee-server.xml" file to a ".config.json" file. You don't have to hand-edit it from scratch. Which leads to... What is the correlation between .cfconfig.json and lucee-server.xml. "I" don't actually know - if the .cfconfig.json overwrites the contents of the lucee-server.xml - or if the JSON file is just "used" in addition to the XML. But the chain of of authority for setting Lucee configuration details, works like this.... Use settings in the lucee-server.xml Use settings in the .cfconfig.json and overwrite any "same" "key" - with the value in JSON file. Use environment variables to overwrite and "same" "key"- with the value in the environment variable. So to finalise all this... (I do NOT use the Lucee Admin at all - I do not know or care what is in lucee-server.xml) I have some VERY general setup in the server.json file (ports / SSL and I have a hard-coded value for the version of Lucee I want to use.) This file is committed to version control. I then have ALL my settings (including datasources and mappings) in a .config.json In that file - I use a "placeholder" for an environment variable - for all sensitive info (passwords / keys / etc) I also use a placeholder for database host / port / userrname too. This file is committed to version control. And while there are multiple ways to do it, In the script that I use to launch CommandBox (which I automate to run on startup) I copy the Lex files I use to the "deploy" folder of the running Lucee instance. This file is committed to version control The Lucee Extensions I use are committed to source control. I use the CommandBox docker image. That way - CommandBox and CFConfig are already loaded and ready to use. My dockerfile (or docker-compose) in my case MAPS the application source code to the "/app" folder in the container from a static resource • for dev ◦ it is my local hard drive ▪︎ I can now edit my source code on my "C" drive and see the results directly in my running app - which is a docker container. ▪︎ I can wholly delete the docker container and have a brand new one up and running in less than a minute. • for production it is a little more complicated... ◦ We use GIT to pull in a release to a local drive on an EC2 instance. ◦ On the EC2 instance we run docker: which in turn loads ▪︎ a container for the database ▪︎ a container for the SMTP server ▪︎ a container for the Lucee App server. Because I have environment variables for the DB Host Server / Port / User / Password I don't need to edit the JSON files so they work on DEV and TEST and PROD. Because the JSON files are named and located as expected by the conventions used by CommandBox, I don't need to worry about copying / moving files to suit my different environments either. The only thing I need to do - and it is a one-off (unless you change passwords, as an example) Is set the database Server / port etc in an environment variable - that matches the environment. EG - I use a DB on my local machine for my dev work But use a DB in a cluster in the cloud for Prod. As long as a DB_HOST environment variable exists and is set correctly - my "code", my startup scripts, etc - do NOT change. What has really helped me - is thinking of my Lucee server / my DB server / etc as something I can produce by a script, on demand. want to try your app on a new version of Lucee? Change the LUCEE_VERSION polaceholder "only". Run the start-up script - you now have your app / your DB / etc all working on a different version of Lucee. CommandBox (as a built-in function) - will download the version you specify - if you haven't previously downloaded by CommandBox. Want to try your application on ACF instead of Lucee? Imagine how you would have done it before? Download the installer from Adobe Configure everything in the installer Configure everything in the CF Admin. (and I previously allowed 3 hours for that process) Now with CommandBox, Change the line in "server.config" from Lucee@VERSION to ACF@version You now have your application running on ACF and all you changed was one line in the server.json file to accomplish this. CommandBox downloaded the ACF CFML server for you. Your previous .config.json all still works on the ACF server. No changes necessary... mappings / datasources / mail server config / etc. All set in .cfconfig.json - used by CommandBox to correctly set up the CFML server - you told it to load. Oh and you can use CommandBox to run as many servers as you like (have resources for) You CAN run a Lucee server and an ACF server both at the same time, on the same physical box. Or load the previous version of Lucee, the current version and the latest snapshot, too - all using the exact same source code - so you can diagnose which Lucee version is messing with your code and which one fixes it. It takes a while to get here - to this level of comfort to this level of evangelism - but it is worth it. Oh I forgot to mention... CommandBox is NOT just for dev or test. It is Production ready and capable. It is not a toy version of anything. Maybe if you think of CommandBox as an orchestration tool - rather than a product of anything "specific" - it might help? Anyway - this is a huge post and a lot to digest. Do not hesitate to ask anything at all.