
How Docker Streamlines Our CF Development
We adopted Docker to make local environments consistent, fast to spin up, and easy to share across the team without manual setup drift or “works on my machine” surprises across our stack.
Historically, each developer’s Mac had a slightly different mix of tools, versions, and settings, which cost time when pairing, onboarding, or reproducing a bug, so we standardized on a Compose-based ColdFusion and SQL Server stack we can boot in one command.
Our CF Dev Stack
For day-to-day work we run Adobe ColdFusion and Microsoft SQL Server as separate containers with named volumes, simple port mappings, and a clean bind-mount to our working code.
services:
cf:
image: adobecoldfusion/coldfusion2023:latest
container_name: cf2023
platform: linux/amd64
ports:
- "8501:8500" # host:container
environment:
acceptEULA: "YES"
password: "YourStrongCFAdminPassword"
enableSecureProfile: "false"
installModules: "sqlserver,debugger"
volumes:
- ./app:/app # your CFML code
depends_on:
mssql:
condition: service_started
restart: unless-stopped
mssql:
image: mcr.microsoft.com/mssql/server:2022-latest
container_name: mssql2022
platform: linux/amd64
ports:
- "1433:1433"
environment:
ACCEPT_EULA: "Y"
MSSQL_SA_PASSWORD: "YourStrongSaPassword!"
MSSQL_PID: "Developer"
volumes:
- mssql_data:/var/opt/mssql
- ./sql/backups:/var/opt/mssql/backup
restart: unless-stopped
volumes:
mssql_data:
- Reproducible spins: new laptop or teammate, same Compose file, same result every time.
- Safe isolation: projects don’t collide on ports, drivers, or versions.
- Fast resets: blow away a container or volume to test a theory, then rebuild in seconds.
- Parity: what we run locally mirrors what we stage and eventually deploy, reducing “surprise” differences at release.
ColdFusion Service
We pin the official Adobe ColdFusion image, auto-install the SQL Server package via CF Package Manager, and map our repository to /app
so edits are live without extra steps.
SQL Server
We run SQL Server 2022 Developer with a named volume for data and a mounted ./sql/backups
folder for restores, which keeps dev data persistent yet easy to back up or reset.
Key Benefits
- Onboarding speed: one command to get a fully working CF + SQL environment, which cuts hours to minutes for new machines.
- Confidence: the environment is source-controlled, reviewed, and reproducible, which reduces configuration drift and “snowflake” setups across the team.
- Context switching: hopping between projects no longer risks breaking global tools or system paths on the Mac.
- Safer experiments: we can test driver updates, package changes, or DB restores without touching the base system.
Gotchas You Should Expect
- Apple silicon: many enterprise images are x64; we set
platform: linux/amd64
so they run flawlessly under emulation on an M-series Mac. - Ports: if 8500 is busy, we map to 8501 on the host and leave 8500 inside the container as the ColdFusion default to keep tooling happy.
- Memory: SQL Server starts reliably when Docker Desktop memory is set to at least four gigabytes on the Resources tab.
- Secrets: we keep credentials in a local
.env
during dev and avoid baking them into images or committing them to git.
How We Roll Out
- Create a project folder with
docker-compose.yml
and anapp/
webroot, then rundocker compose up -d
to start the CF container. - Start SQL Server, verify readiness, and restore a
.bak
when needed via a mounted backups folder inside the container. - Add a datasource in ColdFusion Administrator and run a simple query page to confirm database connectivity.
What’s Next for Xytex
With Docker solid for local dev, we can standardize staging and testing stacks, automate seed data, and keep developer machines clean while focusing on shipping features for the team.
If you’d like a copy of our starter Compose file or a quick loom walkthrough, ping Hale and we’ll share a trimmed template you can drop into your next project.
About the Author


We adopted Docker to make local environments consistent, fast to spin up, and easy to share across the team without manual setup drift or “works on my machine” surprises across our stack.
Historically, each developer’s Mac had a slightly different mix of tools, versions, and settings, which cost time when pairing, onboarding, or reproducing a bug, so we standardized on a Compose-based ColdFusion and SQL Server stack we can boot in one command.
Our CF Dev Stack
For day-to-day work we run Adobe ColdFusion and Microsoft SQL Server as separate containers with named volumes, simple port mappings, and a clean bind-mount to our working code.
services:
cf:
image: adobecoldfusion/coldfusion2023:latest
container_name: cf2023
platform: linux/amd64
ports:
- "8501:8500" # host:container
environment:
acceptEULA: "YES"
password: "YourStrongCFAdminPassword"
enableSecureProfile: "false"
installModules: "sqlserver,debugger"
volumes:
- ./app:/app # your CFML code
depends_on:
mssql:
condition: service_started
restart: unless-stopped
mssql:
image: mcr.microsoft.com/mssql/server:2022-latest
container_name: mssql2022
platform: linux/amd64
ports:
- "1433:1433"
environment:
ACCEPT_EULA: "Y"
MSSQL_SA_PASSWORD: "YourStrongSaPassword!"
MSSQL_PID: "Developer"
volumes:
- mssql_data:/var/opt/mssql
- ./sql/backups:/var/opt/mssql/backup
restart: unless-stopped
volumes:
mssql_data:
- Reproducible spins: new laptop or teammate, same Compose file, same result every time.
- Safe isolation: projects don’t collide on ports, drivers, or versions.
- Fast resets: blow away a container or volume to test a theory, then rebuild in seconds.
- Parity: what we run locally mirrors what we stage and eventually deploy, reducing “surprise” differences at release.
ColdFusion Service
We pin the official Adobe ColdFusion image, auto-install the SQL Server package via CF Package Manager, and map our repository to /app
so edits are live without extra steps.
SQL Server
We run SQL Server 2022 Developer with a named volume for data and a mounted ./sql/backups
folder for restores, which keeps dev data persistent yet easy to back up or reset.
Key Benefits
- Onboarding speed: one command to get a fully working CF + SQL environment, which cuts hours to minutes for new machines.
- Confidence: the environment is source-controlled, reviewed, and reproducible, which reduces configuration drift and “snowflake” setups across the team.
- Context switching: hopping between projects no longer risks breaking global tools or system paths on the Mac.
- Safer experiments: we can test driver updates, package changes, or DB restores without touching the base system.
Gotchas You Should Expect
- Apple silicon: many enterprise images are x64; we set
platform: linux/amd64
so they run flawlessly under emulation on an M-series Mac. - Ports: if 8500 is busy, we map to 8501 on the host and leave 8500 inside the container as the ColdFusion default to keep tooling happy.
- Memory: SQL Server starts reliably when Docker Desktop memory is set to at least four gigabytes on the Resources tab.
- Secrets: we keep credentials in a local
.env
during dev and avoid baking them into images or committing them to git.
How We Roll Out
- Create a project folder with
docker-compose.yml
and anapp/
webroot, then rundocker compose up -d
to start the CF container. - Start SQL Server, verify readiness, and restore a
.bak
when needed via a mounted backups folder inside the container. - Add a datasource in ColdFusion Administrator and run a simple query page to confirm database connectivity.
What’s Next for Xytex
With Docker solid for local dev, we can standardize staging and testing stacks, automate seed data, and keep developer machines clean while focusing on shipping features for the team.
If you’d like a copy of our starter Compose file or a quick loom walkthrough, ping Hale and we’ll share a trimmed template you can drop into your next project.
About the Author

