http://coldfusion.com logo
Join Slack
Powered by
Hi everyone, I’m hoping to get some clarification...
# wheels-dev
y
Hi everyone, I’m hoping to get some clarification regarding Wheels 3.0 architecture. We’re currently running multiple Wheels 2.x applications under a single Lucee 5 server instance. This setup has been stable for us, and ideally we’d like to continue using a similar multi-app architecture going forward. From what I’ve gathered, Wheels 3.0 may not support this pattern anymore, but I wanted to confirm whether that’s actually the case. Is there any supported way to continue running multiple Wheels 3 apps under a single Lucee server? Or is the intended architecture now strictly one server per app? If maintaining the multi-app setup isn’t supported, are there any recommended workarounds or migration paths that would allow something functionally similar? Apologies if I’m misunderstanding something — just trying to evaluate our upgrade path carefully. Thanks in advance for any guidance.
z
Thanks for asking, give me some time. I will write a detail response for your convenience.
Thank you for the thoughtful question, this is absolutely the right consideration when evaluating an upgrade. Wheels 3.0 does not remove the ability to run multiple applications under a single Lucee server instance. That capability is still fundamentally supported by Lucee itself. However, the architectural direction in Wheels 3.0 assumes a more modern, isolated application structure particularly with the move to: A dedicated 
public/
web root per app • Framework core living in 
/vendor/wheels
• CLI-driven project scaffolding • Clear separation between server-level and app-level concerns What This Means Practically You can still run multiple Wheels 3 applications on a single Lucee server, provided that: Each application has its own web context (separate web root). 1. Each app maintains its own 
public/
directory as the web-accessible root. 2. URL rewriting is configured per site (via web server or Lucee mapping). This is effectively the same pattern used by modern frameworks like Laravel, Rails, etc., where multiple apps share a runtime but not a single web root. What Is No Longer Recommended and What is discouraged (and may cause issues) is: • Running multiple apps inside the same physical web root • Sharing framework core files across apps manually • Relying on legacy 2.x routing assumptions (
root.cfm
, etc.) Wheels 3 assumes one application per project directory with clean boundaries. If your goal is operational efficiency (one server, multiple apps), you can do like Single Lucee Server, Multiple Sites (Supported) Configure each Wheels 3 app as its own site/context in Lucee. • Point each site to that app’s 
/public
directory. • This is fully aligned with the 3.0 architecture. Is It “One Server Per App”? Not strictly. It is “one application per project structure,” but multiple applications can absolutely share a Lucee server instance as long as they are isolated at the web context level.
LMK if that makes sense and ask any questions. We are here to help on every step.
y
Thanks for the guidance! Here’s where we’re at now. Our setup: We have a server root folder with a single 
server.json
, and each app in its own subfolder. Within each app, we have the standard Wheels 3.0 structure — 
wheels
, 
wirebox
, and 
testbox
installed under 
vendor/
via 
box install
. We’ve copied over our existing controllers, models, views, etc. into the 
app/
folder and our configuration into the 
config/
folder. Three issues we’re hitting: 1. Clean template works fine With a fresh scaffold (before copying over any existing code), we can visit the congratulations page and perform a reload — no issues. 2. Reload doesn’t pick up config changes After copying our 
settings.cfm
into 
config/
, changes don’t take effect on reload. For example, we set a variable in 
settings.cfm
, did a 
writeDump
in a request to verify it, and it didn’t show up until we did a full server restart. It seems like the Wheels reload (
?reload=true
) isn’t actually re-including the config files. 3. After server restart, reload is broken Once we restart the server (so the config changes take effect), subsequent reloads fail with this error. Here is the reload url we were using: 
<http://localhost:3000/[PROJECT_FOLDER_NAME]/public/index.cfm>
I turned off url rewrite in 
settings.cfm
Copy code
lucee7/
├── server.json         
├── app1/
│   ├── public/             
│   ├── app/        
│   ├── config/        
│   ├── vendor/       
│   ├── plugins/
│   ├── tests/
│   └── box.json
├── app2/
│   ├── public/
│   ├── app/
│   ├── ...
├── ... (all other apps)
z
@Yuxin The main thing I’d like to see is the contents of your 
server.json
, along with where your 
Application.cfc
and 
index.cfm
are located in your folder structure. Those are the key files involved in how Lucee resolves the application and web root. They should help clarify what’s causing the error. If they don’t tell the full story, I may need a bit more detail, but that would be the best place to start.
You can share via email or DM me or you can create a discussion over git or you can create issues under git issues.
4 Views
Open in Slack
PreviousNext
Powered by