Come learn about of the flagship features of CommandBox Pro. CommandBox Multi-site allows you to completely replace your web server with CommandBox, hosting multiple websites all in a single process. Each site has its own web root, rewrites, logs, configuration, and HTTP bindings! This is a major new enhancement to CommandBox servers and finally bring CommandBox on par with other web servers and allows you to simplify your entire tech stack down to a single moving part for deployment.

1. CommandBox
Multi-Server
The only tool you’ll ever need
Brad Wood
@bdw429s

2. CommandBox Multi-Site

3. CommandBox Multi-Site
● Simple, standalone server
● Contains web server HTTP/SSL/AJP binding
● Unparalleled configurability & portability
● Only 1 webroot
● Only 1 set of rewrites
● Only 1 set of virtual directories
● Only 1 HTTP/SSL/AJP port
● Only 1 profile/lockdown config
● Only 1 set of welcome files
● Only 1 set of Mime Types
● Only 1 directory browsing flag

4. CommandBox Single Site Server (default)

5. CommandBox Multi-Site
ModCFML!!
● Simple, standalone server
● Contains web server HTTP/SSL/AJP binding
● Unparalleled configurability & portability
● Only 1 webroot Multiple webroots
● Only 1 set of rewrites
● Only 1 set of virtual directories
● Only 1 HTTP/SSL/AJP port
● Only 1 profile/lockdown config
● Only 1 set of welcome files
● Only 1 set of Mime Types
● Only 1 directory browsing flag
● Requires web server in front to define sites & pass HTTP headers

6. CommandBox Lucee Multi-Context

7. CommandBox Adobe CF Multi-Context

8. CommandBox Multi-Site
● Simple, standalone server
● Contains web server HTTP/SSL/AJP binding
● Unparalleled configurability & portability
● Multiple Webroots (sites)
● Virtual directories per site
● Multiple HTTP/SSL/AJP bindings per site
● Profile/lockdown config per site
● Welcome files per site
● Mime Types per site
● Directory browsing flag per site
● Supports Adobe CF & Lucee Server
● No additional web server needed!

9. CommandBox Multi-Site
● Huge refactoring of server launching
● Huge refactoring of Runwar code
● Addition of “sites” object to server.json
● Addition of “web.bindings” object to server.json
● New JSON file conventions for defining sites
● New tray icon menus
● Static files served from Undertow Resource
handler instead of default servlet
● Access log for each site
● Total isolation of settings for each site
● Default, server level settings that apply to all sites
● Host Header support for many sites on same IP:port
● Takes the place of your full web server AND servlet
● Part of CommandBox Pro license

10. CommandBox Multi-Site
● FREE for development and testing usage
● Fully(*) backwards compatible
● Default behavior is still just a single site
● Supports old HTTP/SSL/AJP port config
in addition to new “bindings” syntax
● Ready on the 6.0.0-alpha builds for you to test
(*) The notable exception being Tuckey

11. CommandBox Multi-Site
Server-wide Settings
● JRE/JDK the server runs on
● JVM args, heap size
● CF Engine/version
● Console log
● Tuckey Rewrites (part of servlet)
● Environment Variables

12. CommandBox Multi-Site
Per-site Settings
● GZIp enabled and GZip predicate
● Access log
● Use proxy forwarded IP
● CommandBox Server Rules (Undertow
Predicate Language)
○ SSL settings (HSTS, SSL Redirect)
○ Block CF Admin
○ Block flash remoting
○ Block sensitive paths
● Security
○ Basic auth
○ Client cert auth
○ Security predicate
● Custom error pages (404, 500, etc)
● Mime types
● Welcome files
● Allowed file extensions
● Directory browsing
● Aliases/Virtual dirs
● File cache settings
● Case sensitive paths
● Web root
● Server Profile

13. CommandBox Multi-Site
● By default, “server start” does the same thing it’s always done
● Trigger multi-site simply by defining a “sites” object
● Each “site” object can contain all the same properties as a server.json “web” object
● In multi-site mode, the “web” object holds default settings, applied to all sites unless they
override that setting
● “webroot” and “name” is really the only required settings for a site
● Bindings can be declared at server level if all sites want to be on port 80/443 for example
● New “hostAlias” setting for setting per-site host headers
● Bindings map incoming requests to sites in this order
○ Matches exact IP:port and host header
○ Matches *:port and host header
○ Matches exact IP:port and wildcard host header
○ Matches *:port
○ Is “default” site

14. CommandBox Multi-Site
{
"name":"multiverse",
"web":{
"bindings":{
"HTTP":{
"listen":"0.0.0.0:80"
}
}
},
"sites":{
"client-1":{
"hostAlias":"client1.com,www.client1.com",
"webroot":"/var/www/client1/"
},
"client-2":{
"hostAlias":"client2.com,www.client2.com",
"webroot":"/var/www/client2/"
}
}
}

15. CommandBox Multi-Site
● New .site.json convention
● If file exists in web root of site, it is automatically loaded and merged into that site’s
settings
● Similar to web.config (IIS) or .htaccess (Apache) conventions
● Each .site.json file contains the same JSON structure as the “site” object
● Allows main server.json file to contain shared settings and “point” to the web roots and
all site-specific settings are kept with that site
● CommandBox-dotenv module will load any .env file also in the site’s web root and those
env vars will ONLY be visible to that .site.json file

16. CommandBox Multi-Site
.site.json
{
"profile":"production",
"directoryBrowsing":false,
"hostAlias":"example.com,www.example.com",
"GZipEnable":false
}

17. CommandBox Multi-Site
{
"name":"multiverse",
"web":{
"bindings":{
"HTTP":{
"listen":"0.0.0.0:80"
}
}
},
"sites":{
"client-1":{
"siteConfigFile":"/var/www/client1-site.json"
},
"client-2":{
"siteConfigFile":"/var/www/client2-site.json”
}
}
}

18. CommandBox Multi-Site
{
"name":"multiverse",
"web":{
"bindings":{
"HTTP":{
"listen":"0.0.0.0:80"
}
}
},
"siteConfigFiles":"/var/www/sites-enabled/*.json"
}

19. CommandBox Multi-Site
● If no bindings are provided, CommandBox will still pick a random
port on localhost
● In multi-site mode, a random port will be assigned to each site
● You can still use the “simple “ old way of declaring a single
HTTP/SSL/AJP port at the “web” level or inside a specific
“sites.my-site”.
● When using the old way, the “host” param defines the IP address, or
a hostname that resolves to a local IP for backwards compatibility.
● A new hostAlias property can be defined at the site level and applies
to all bindings no matter how they are defined.

20. CommandBox Multi-Site
● New “bindings” object can be provided in the “web” or any “site”
object.
● Top level “http”, “ssl”, and “ajp” objects can contain a single binding
object or an array of binding objects
● Each binding object can contain
○ Listen - IP:port where IP can be * or 0.0.0.0 or omitted
○ IP (mutex with “listen”)
○ Port (mutex with “listen”)
○ Host - list or array of host header names to match. * or empty
means match any hostname

21. {
"web": {
"bindings": {
"http": [
{
"listen": "*:80",
"host": [
"www.mysite.com",
"dev.mysite.com"
]
},
{
"listen": "127.0.0.1:8080"
}
],
"SSL": {
"listen": "0.0.0.0:443",
"host": "www.mysite.com",
"certFile": "myCert.pfx",
"keyPass": "$ecret"
},
"AJP": {
"listen": "8009"
}
}
}
}