Masa CMS does not need exotic cloud infrastructure. It needs a well-run CFML runtime, a servlet container, a supported database, and a file strategy that will not surprise you later.
That makes AWS EC2 a practical fit. Masa CMS is the community-governed, open-source continuation of Mura CMS, and because it is built entirely on CFML, the real hosting question is simple: can you run Lucee and Tomcat cleanly on AWS?
This guide walks through a production-minded path for hosting Masa CMS on EC2 with Lucee, Tomcat, Amazon RDS, and the AWS services that make the deployment easier to secure and operate.
Start with what Masa CMS requires
Before choosing an EC2 image or database engine, confirm the application requirements.
Masa CMS can run on:
Lucee 4.5.1.000 or higher
Adobe ColdFusion 10 or higher, if you use commercial ColdFusion instead of Lucee
For this guide, the runtime path is Lucee on Tomcat, which is common for open-source CFML hosting and lines up well with EC2.
Masa also needs a supported relational database. The supported list includes:
Database | Minimum supported version |
MySQL | 5+ |
PostgreSQL | 8+ |
Microsoft SQL Server | 2000+ |
Oracle | 10g+ |
The datasource must support CLOB fields for long-text content. The database account also needs the permissions Masa expects during setup and updates:
`SELECT`
`CREATE`
`INSERT`
`DROP`
`UPDATE`
`ALTER`
`DELETE`
For a production system, do not treat those permissions casually. Use a database user created for Masa, scope it to the Masa database, and store its credentials securely.
One more runtime note matters if you are not using Lucee. If you run Masa CMS on Adobe ColdFusion 2023 or later, add this JVM argument to `jvm.config`:
```text
--add-opens=java.base/java.util.zip=ALL-UNNAMED
```
That setting is easy to miss during a migration or new build. Without it, the application may not behave correctly.
Masa’s own getting-started approach supports flexible infrastructure. Local developers can use Docker and CommandBox for quick starts, while production deployments can run on AWS, Azure, or self-managed hardware. On AWS, the most direct production shape is simple: EC2 for Lucee and Tomcat, RDS for the database, and shared storage if the site grows beyond one instance.
Choose the EC2 hosting path
There are three realistic ways to host Masa CMS on AWS EC2 with Lucee and Tomcat. The right choice depends on how much control you need and how quickly you want to deploy.
Path | Best fit | Tradeoff |
AWS Marketplace AMI | Fastest production start | Less custom from day one |
Hand-built EC2 image | Maximum control | More setup and maintenance |
Containerized deployment | Repeatable release pipeline | More moving parts early |
For many Masa CMS deployments, the fastest path is the AWS Marketplace image from Ortus Solutions.
The Ortus Solutions Lucee CFML Server listing bundles:
Ubuntu Server 24.04 LTS
Lucee 5.4.6.9
Tomcat 9.x
Nginx as a reverse proxy
It is also hardened against the Adobe ColdFusion Lockdown Guide and CIS Benchmark Level 1. That does not remove the need for your own security work, but it gives you a stronger starting point than a bare operating system and a manual install.
A hand-rolled EC2 image makes sense when you need tighter control over OS packages, Tomcat configuration, Java versions, deployment scripts, or compliance requirements. In that case, build the image intentionally and document every step. Do not turn a one-off server session into your production standard.
Containers can be a good later step, especially for blue-green deployments or mature CI/CD pipelines. But they are not required to run Masa well. A single EC2 instance with a managed database can be the right first production architecture when it is secured, backed up, and monitored.
Provision the EC2 instance
Start with the network and instance basics.
Place the EC2 instance in a VPC with a public-facing load balancer or public subnet only where needed. For a simple single-instance deployment, Nginx can terminate web traffic on the instance, but many production teams will use an Application Load Balancer for TLS and routing.
At minimum, plan for:
A security group allowing web traffic on `80` and `443`
No public SSH access if you use AWS Systems Manager Session Manager
An IAM role attached to the instance for CloudWatch, Secrets Manager, and Systems Manager access
EBS volumes sized for the application, logs, and temporary working files
Automated snapshots or a backup plan for instance-level recovery
If you use the Marketplace AMI, much of the Lucee, Tomcat, and Nginx stack is already present. The next work is configuration, not installation.
If you build manually, the high-level stack looks like this:
Install Java supported by your Lucee and Tomcat versions.
Install Tomcat.
Deploy Lucee as the CFML engine.
Put Nginx in front of Tomcat.
Configure the Masa webroot.
Set up the datasource in Lucee Admin.
Lock down admin paths and server access.
Production CFML hosting lives in the details. File ownership, Tomcat service configuration, JVM memory, request timeouts, and log rotation all matter.
Install or deploy Masa CMS
Once the CFML runtime is ready, deploy the Masa application files to the webroot served by Tomcat through Lucee.
A typical path is:
Get the Masa CMS application files from the official project source.
Place the files in the configured webroot.
Confirm Tomcat and Lucee can read and write where Masa needs file access.
Configure the datasource in Lucee Admin.
Run the Masa setup process.
Validate that the admin area, public site, and asset handling work.
File permissions deserve extra care. Masa needs to work with uploaded assets, generated files, cache directories, and plugin or theme files depending on how the site is used. Do not fix permission problems by making broad directories world-writable. Use the Tomcat service user and a clear ownership model.
For the Lucee datasource, define the DSN with the database type, hostname, database name, username, and password. In production, keep the actual credential in AWS Secrets Manager rather than in a plaintext bootstrap script or copied setup notes.
If you are migrating from Mura CMS, this is also where the content and schema path matters. Masa continues the Mura lineage, but a real migration still needs planning. Confirm extension compatibility, custom code, theme assumptions, plugins, scheduled tasks, and database changes before cutting over.
Put the database on Amazon RDS
Masa’s supported databases map well to Amazon RDS.
For most new deployments, MySQL-compatible or PostgreSQL-compatible choices are the simplest fit:
Amazon RDS for MySQL
Amazon RDS for PostgreSQL
Amazon Aurora MySQL-Compatible Edition
Amazon Aurora PostgreSQL-Compatible Edition
Aurora can work as a managed alternative to self-hosted MySQL or PostgreSQL when you want AWS-managed scaling and availability features. Standard RDS is also a strong fit for many Masa sites and is often easier to reason about for small to mid-sized deployments.
Create the database in private subnets when possible. The EC2 instance should reach it over private networking. The database should not be open to the public internet.
For the database user, grant the permissions Masa needs, including CLOB support and the DDL permissions used during installation and updates. That does not mean every human or deployment process should have broad database access. Separate app credentials from administrative credentials.
Also configure:
Automated backups
A reasonable backup retention period
Encryption at rest
Parameter groups if your workload needs database-level tuning
Monitoring for CPU, memory, storage, connections, and slow queries
The database will usually become more important than the EC2 instance over time. An app server can be rebuilt from an image. Content and schema need stronger protection.
Decide how files will work
A single EC2 instance can store user uploads and site files on its own EBS volume. That is acceptable for a simple starting architecture, as long as backups are in place.
The question changes when you add more than one instance.
If two EC2 instances serve the same Masa site, they need a shared answer for files that users upload or the application generates. Amazon EFS is the common AWS service for shared POSIX-style file storage across instances.
Use EFS when:
You run multiple EC2 instances behind a load balancer
Uploaded assets must be available to every instance
You want app servers to be replaceable
You plan to use Auto Scaling
Do not wait until after scaling to think about this. If the first instance stores everything locally and the second instance cannot see those files, the site will behave inconsistently.
A practical pattern is:
Keep application code deployable from source or artifacts.
Keep database state in RDS.
Keep shared user-controlled files in EFS.
Keep logs flowing out to CloudWatch.
That gives each layer a clear job.
Secure secrets from day one
Do not store production database passwords in plaintext datasource files, shell history, setup scripts, or AMI notes.
Use AWS Secrets Manager for:
RDS database credentials
Lucee administrator password
Application secrets
Integration credentials used by the site
The EC2 instance role can read only the secrets it needs. That is better than embedding passwords into the server image or sharing them among admins.
Lucee datasource configuration still needs to receive the credential at runtime or during controlled provisioning. How you do that depends on your deployment process, but the principle is the same: secrets should be retrievable, rotated, audited, and removed from human-readable build artifacts.
Also change any default passwords from AMIs, setup tools, or admin interfaces. Lock down Lucee Admin and any server-level admin path so it is not exposed broadly on the internet.
For network security, keep the rules plain:
Public users reach the site over HTTPS.
The web tier reaches RDS privately.
Admins use Session Manager instead of open SSH.
Only required ports are open.
Security groups describe intent clearly.
Use Systems Manager instead of opening SSH
AWS Systems Manager Session Manager lets you connect to the EC2 instance without opening inbound SSH.
That pairs well with a hardened AMI. Instead of allowing port `22` from an office IP range or, worse, from the internet, you attach the right IAM permissions and connect through AWS-managed channels.
Session Manager gives you:
Shell access without public SSH
IAM-controlled access
Optional session logging
A cleaner security group
Better fit with locked-down production environments
You still need operating system discipline. Keep packages updated, review service accounts, remove unused tools, and patch the stack. Session Manager solves access exposure, not server maintenance.
Send logs and metrics to CloudWatch
A Masa CMS site on Lucee and Tomcat produces several kinds of signals:
Tomcat logs
Lucee logs
Nginx access and error logs
Application-specific logs
Operating system metrics
JVM behavior
RDS performance data
Send the important logs to Amazon CloudWatch. Local logs are useful during troubleshooting, but they disappear when an instance is replaced and are harder to search across systems.
CloudWatch also gives you the metrics needed for alarms and future scaling. Even if you start with one EC2 instance, collect the data you would need later for Auto Scaling decisions.
Good early alarms include:
EC2 CPU pressure
Low disk space
High memory pressure if reported through the CloudWatch agent
Tomcat or Nginx process failure
RDS CPU or connection spikes
RDS free storage approaching a limit
Load balancer unhealthy host count if you use an ALB
For JVM-based apps, memory behavior matters. Watch heap usage, garbage collection symptoms, request latency, and error logs together. A CPU graph alone rarely tells the whole story.
Configure Nginx, Tomcat, and Lucee for production
The Marketplace AMI gives you a working stack, but production settings still need review.
For Nginx, check:
TLS configuration
Redirects from HTTP to HTTPS
Proxy settings to Tomcat
Request body limits for uploads
Static asset handling
Access and error log paths
For Tomcat, check:
Service user and permissions
Connector settings
Thread settings
Timeouts
JVM memory options
Restart behavior
For Lucee, check:
Datasource settings
Admin password
Extension requirements
Caching settings
Mail server settings if Masa sends mail
Error handling behavior
Whether debugging output is disabled in production
Masa will only be as reliable as the layers underneath it. A default server can run the app. A production server needs clear limits, secure access, repeatable configuration, and logs that explain what happened.
Plan for scaling before you need it
A single EC2 instance is often enough for a moderate Masa site. The key is to avoid painting yourself into a corner.
If traffic grows, the path usually looks like this:
Put an Application Load Balancer in front of the app tier.
Move shared files to EFS if they are not already there.
Use a launch template or custom AMI for repeatable EC2 instances.
Store sessions in a way that supports multiple app servers, if needed by your configuration.
Add Auto Scaling based on real CloudWatch metrics.
Use deployment automation so every node runs the same code.
Blue-green deployments are easier once the app is packaged and configuration is externalized. That may lead to containers later, but EC2 images and launch templates can also support controlled releases.
The main point is separation. Keep app servers replaceable, keep data in managed services, and keep secrets outside the image.
Validate the deployment before launch
Before pointing production DNS at the new Masa site, run through a practical checklist.
Confirm the application works:
Public pages load correctly.
Admin login works over HTTPS.
Content editing and publishing work.
Image and file uploads work.
Scheduled tasks run as expected.
Email sending works if configured.
Custom themes, plugins, and integrations behave correctly.
Confirm the infrastructure works:
EC2 restarts cleanly.
Tomcat and Nginx start on boot.
Lucee connects to RDS after reboot.
Logs appear in CloudWatch.
Alarms fire to the right destination.
RDS backups are enabled.
EBS snapshots or AMI backups are scheduled.
Secrets are not stored in plaintext scripts.
Confirm security basics:
No open SSH is required.
Admin interfaces are restricted.
TLS is valid.
Security groups allow only required traffic.
Default credentials are changed.
OS and package updates are current.
For a migration from Mura CMS, add content comparison and redirect testing. Confirm URLs, assets, metadata, forms, and custom code before the final cutover.
Know what success looks like
A clean Masa CMS deployment on AWS is not complicated, but it should be deliberate.
The finished architecture usually looks like this:
Lucee and Tomcat running on EC2
Nginx or an AWS load balancer handling web traffic
Amazon RDS or Aurora storing the database
AWS Secrets Manager protecting credentials
CloudWatch collecting logs and metrics
Systems Manager Session Manager replacing open SSH
EFS ready when multiple instances need shared files
That is the practical model behind How to Host Masa CMS on AWS EC2 with Lucee and Tomcat. It is not a special CMS-only architecture. It is a serious CFML application stack on current AWS services.
For teams coming from Mura, the main work is not only standing up servers. It is also validating the upgrade path, custom code, database behavior, file storage, and operational model. CF Webtools handles Masa hosting builds on AWS end to end, including AMI selection, RDS setup, EFS planning for multi-instance file storage, and Mura-to-Masa upgrade work.
When the build is done well, the site should feel boring in the best way: clean deployments, private database access, protected credentials, searchable logs, restorable backups, and a clear path from one EC2 instance to a larger AWS footprint when the site needs it.