Can one domain name host DSP and my WebApp? Bad idea?

I would like to have one web address serve both DSP and my web app? Two reasons for this: 1) encapsulation of the functionality and 2) ability to share the SSL certificate.

I’m sure this is possible, but unsure of the changes are required to get me there and what might be the best shortest path. Or, if maybe I’ll be creating more problems than I’m solving. Here is what I think to be true:

  • DSP by default is not configure for this because it uses index.php to drive all requests.
  • DSP’s index.php can related files are expected to be in a specific hierarchy (references like /…/bootstrap/autoload.php’)

I would like to have 3 urls something like:

The DSP install (greatly simplified) has:

→ bootstrap
→ server
→ public (apache serves from here)
→ → css
→ → df-swagger-ui
→ → dreamfactory

My guess is that this could be done with some Apache config, but that may or may not cause problems in my hosted environment (Plesk). As I have written this, I’m increasing think this is just a bad idea. Please share your thoughts?

Of note, I have 2 use cases I looking to implement and neither have my web app calling the DSP:

  1. DSP used to enhance data for WebApp by an external ETL process.
  2. DSP used solely by mobile app, but would like to have simple web console to that data for maintenance and such. No public end users of the web app.

You can totally use a single domain for your DF instance and WebApp without touching apache config. Here is what you need to do. Put your WebApp inside the public directory or create a symlink to your WebApp inside the public directory. Let’s call it my_web_app. Create another symlink inside the public directory for the DF admin app (DSP console).

cd /path/to/df/install/root/public
ln -s dreamfactory/dist dsp

Now edit the .env file (It’s a hidden file) that’s inside the DF install root. Uncomment the following line


Set this to


That’s all you need.

You could also store your WebApp using DF2 storage service and set the DF_LANDING_PAGE to this storage path. For example if you store your app using the default storage service called files inside a directory called my_web_app and make this directory public from files service config page. Then you can access your app using url You can then set DF_LANDING_PAGE to this url. This is a better approach as it will allow you to manage your app from within the DF2 instance as well as gives you the freedom to store your app locally or on the cloud using remote storage service such as S3, Racksapce etc.

1 Like

I think there may be more to make this work, I am missing something, or my question has been misunderstood.

  • The .htaccess at the root seems to control the laravel app and thus both the admin and the api features.
  • Without the DSP .htaccess file, there will be nothing directing the /api requests through DSP. Right?
  • A pretty easy rewrite rule for this, but cannot see it working without.
  • Unsure why the DF_LANDING_PAGE change is recommended because in both my use cases DSP does not need to know about my webApp and my webApp does not need to know about DSP. I probably need to do some more reading on this and maybe only needed as described below in my 2nd use case. I want my WebApp at [] not [].

In my first use case, I want Plesk to manage my WebApp. It is cool that the web app could be installed within DF2 storage, but that would probably break other things. DSP is only a conduit for updating the app’s data behind the scenes.

For my second use case (cloud data storage for mobile app with simple admin web app), DF2 storage would probably work, but this really changes the system configuration putting DSP at the center of the world. Not necessarily the way I was thinking of configuring things, but probably worth considering. And with proper web server config, I could get it address the way I want.