Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
Is it possible to run multiple domains/sites to same fuel setup using nginx and modules?
  • Currently I am using modules to write multiple sites/applications on top of the same fuel instance.  All my base dev setups are working fine, starting to run into issues as I try to setup to serve all apps together off same server(s) with nginx.


    Right now I have the following applications/modules => admin, public, auth

    Currently I have default route to go to auth/login, assuming people will be logging into the admin application.

    I have a separate domain, lets call it that I would like to map to the public module acting as a public facing website/app.

    Here is a nginx config fragment which seems like it should work but still serves up the default _root_ value pointing to auth/login based on my routes.php config:


           root /var/www/fuel_root_dir;
           index index.php index.html index.htm;
           charset utf-8;


           location ~* \.(ico|css|js|gif|jpe?g|png)(\?[0-9]+)?$ {
                    expires max;
                    log_not_found off;

            location / {
                    try_files $uri $uri/ /index.php?/public/$request_uri;


    Anyone setup multiple sites/domains to map to different modules?  Is this an issue that has to be solved in routes.php config setup.. ie: do I need to have _root_ configs for each module?

  • HarroHarro
    Accepted Answer
    You can not map to modules, modules are just a collection of classes.

    If you have multiple websites (i.e. multiple hostnames) you have multiple virtual host definitions, and each should point to a separate /public folder which contains the index.php for that website.

    You can share the core, modules and packages amongst multiple installations quite easily, just create a shared folder that contains:
    - fuel16/core
    - fuel16/packages
    - fuel16/packages/<your shared packages>
    - fuel16/modules
    - fuel16/modules/<your shared modules>

    Change COREPATH in your index.php (and in oil and in phpunit if needed) to point to the shared fuel/core instead of the website's fuel/core. After you've done this you can remove fuel/core from all installed websites (where you have made this change). Include the version in the shared folder name, because there will come a time you want to upgrade one site, but not another.

    Next move all your shared modules and packages, and change the config.php of all websites, so that the modules and packages paths contain both the local website path and the shared path, with the local one first. This will allow you to override shared packages locally. Do not change PKGPATH, it still needs to point to the local application package folder

    After you've done this, you've ended up with slimmed-down installations, basically only containing the application code (and modules/packages specific to the application).

    Per application you can use routes to decide which modules will be available and which not, and which routes should point to which controllers, as always.

    You can do the same with composer packages, install them all in a central folder, and change VENDORPATH to point to that folder (1.6+).

    We use this setup on all our servers, and it works very well.
  • What I have been trying to accomplish with my fuel usage is everything is shared and modules would be the separation between apps.  Sounds like I have been approaching it wrong.  Shared app/models/packages/ has been my goal.


    With your suggestions above could I share my app/* between sites?

  • I'm trying to understand what exactly you want. A site === an app, so app is per definition site specific.

    If you have stuff you need to share between multiple applications on the code level, use a package or a module. A package can be added to the global namespace, so code in there can be added transparently to app, even if its in a package. Auth for example does that.

    If you have stuff you need to share on the application level (so not only code but also data), you ideally should to REST calls between apps, to keep the apps completely seperated on the logical level.
  • In my current application setup I have the following modules:






    The way I am defining "site" is that each of those modules is one.  I have admin, partner, and api setup as subdomains for my main domain.  I have another domain that I would like to run as a main public website.

    The sub-domain approach has worked well in my first attempts.., but attempting to pass the public module domain gets miss-directed by the _root_ route value.


    I would like to avoid going the REST route just to share models and data.  I might try to put some customization in that allows for work-around for the _root_ route config

  • HarroHarro
    Accepted Answer
    Ah, ok. That's quite a non-standard setup you've got here.

    This means you'll need rewrite rules, so you can do
    - => RewriteRule ^(.*)$ index.php/admin/$1 [L]
    - => RewriteRule ^(.*)$ index.php/partner/$1 [L]
    - => RewriteRule ^(.*)$ index.php/api/$1 [L]

    and so on.

    This will make sure a URL like will be seen by the Fuel routing engine as "admin/controller/method", which will load the "controller" from the admin module.

    But because of this, controllers in other modules, and controllers in app, will never be directly accessable by your users, unless you deal with that in your module routing, or you setup a front controller in your module with internal HMVC calls...

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion