Change your Nginx docroot

Change the folder Nginx serves from on TurboStack, with a symlink, the 50main.conf root directive, or a platform-managed override.

Some applications may require you to use a different document root (docroot) than the typical directory of ~/public_html. The docroot is the directory Nginx serves a site's files from. Other times, your own application deploy flow may require you to change Nginx's docroot, for example to point it to ~/current. In this guide, we'll quickly go over some common situations and ways to set this up.

The easiest way to make sure Nginx reads application files in the correct directory, is simply by turning the default directory into a symlink, pointing to the desired directory. Consider the following default directory setup:

Let's say your app typically deploys with a directory releases/, which contains the actual different releases and a symlink current, linking to the most recent release. This is the default Deployer setup. In that case, you can simply remove the existing, empty public_html directory and replace it with a symlink:

Using the Nginx docroot

Alternatively, you could change the actual path Nginx looks for. In your home directory you'll find the ~/nginx config directory, containing the 50main.conf file. Here, you'll find your main application Nginx config, including the docroot. Depending on your configured app type, the exact contents of this file will change. However, you can edit this file as desired. An example of how the docroot is defined in this file is below:

root /var/www/sander/public_html;

Here you could change the public_html part to any path as required by your application. After editing, apply the change by reloading Nginx with the TurboStack CLI:

tscli nginx reload

Letting the platform manage it

The two methods above are yours to maintain. There is also a platform-native override that changes the served folder and keeps the generated configuration in sync, so it survives platform updates without you editing 50main.conf by hand. That is the cleanest option when a framework serves from a fixed subfolder such as public or web, and it is the one to ask Support for if the symlink does not suit your deployment.