← back to code snippets

NGINX configurations to run Create-React-App from a subdirectory of WordPress

Posted on December 21st, 2017

By combining NGINX with UI Component Library, you can set yourself free from being tied to just one CMS or environment for your site. I really like using WordPress, but for some pages in my site, a custom built React app works much better for me. This has lead me to find that NGINX server configurations can set you free from using just one environment – all that matters is that the style guide and UI components are usable by anything.

That’s because using NGINX, you can serve pages from any app at any URL. To make it clearer, say your WordPress set up is located in var/www/wordpress-site. The following NGINX configuration will serve your site to anyone visiting www.wordpress-site.com:

server {
        listen 80 default_server;
        listen [::]:80 default_server;

        root /var/www/wordpress-site;
        index index.php index.htm index.html;

        server_name www.mysite.com;

        location / {
          #try_files $uri $uri/ /index.php?$uri$args?$query_string;
          try_files $uri $uri/ /index.php?$uri=$uri&$args;


        location ~ \.php$ {
               include snippets/fastcgi-php.conf;
               fastcgi_pass unix:/run/php/php7.0-fpm.sock;


  • The root is set to the directory of your WordPress site root /var/www/wordpress-site;, and the rest of the location clause ensures all the different links and query strings will work.

Serving a Create-react-app site from a subfolder.

Now, what if you want one of the subdirectories such as www.mysite.com/react-application to serve a page from a completely different environment?

In my case, I had a separate react app (made with Create-react-app) for the exact same brand located in a sibling directory. To avoid rebuilding this to work inside my WordPress setup, I just added a new location clause to the NGINX configuration:

location ^~ /react-application {
	alias /var/www/html/react-application/build;

	subs_filter href="/ href="http://www.mysite.com/react-application;
	subs_filter src="/ src="http://www.mysite.com/react-application;
  • The location is set to ^~ /react-application , meaning that the rules created in the location braces will become effective when somebody visits www.mysite.com/react-application
  • The alias is set to the static build folder of my Create-react-app site /var/www/html/react-application/build. That’ll be served when the visitor hits your subdirectory url www.mysite.com/react-application
  • Next, the two subs_filter lines replace any reference to href and src urls that start with the React app’s home directory / with the new complete URL. That will ensure all your CSS and JS files are located and served correctly by NGINX.

The final thing, in the case of Create-React-App is that any references to createBrowserHistory in your react router need to be replaced by createHashHistory, as Browser History won’t work with the above NGINX configuration.

If it’s not a static site

If you’re not serving a static site, but are using something like PM2 or forever to serve your site, here’s the config for that:

location ^~ /react-application {
	rewrite ^/react-application(/.*)$ $1 break;

	proxy_pass http://localhost:5000;
	proxy_http_version 1.1;
	proxy_set_header Upgrade $http_upgrade;
	proxy_set_header Connection 'upgrade';
	proxy_set_header Host $host;
	proxy_cache_bypass $http_upgrade;

	subs_filter href="/ href="http://www.mysite.com/react-application;
	subs_filter src="/ src="http://www.mysite.com/react-application;


The important differencee here is the proxy_pass. Now when the url is www.mysite.com/react-application, the proxy_pass serves the app being run on a specific port by your pm2/forever server.

That’s it

That’s it really - this is great if you’ve got one common component library being read by all your different apps.