Configuring Joget Behind a Reverse Proxy with Custom Path Aliases

When deploying Joget in enterprise environments, it is common to place the application behind a reverse proxy (such as Nginx or Apache) for purposes such as load balancing, custom routing, or security. A frequent requirement is to access Joget using custom paths or aliases instead of the default /jw context path. For example, organizations may want to serve Joget applications under routes like /engage/dev or /engage/qa, or even completely hide the /jw path through URL rewriting.

This article explains the reverse proxy path rewriting, and provides a supported workaround using symbolic links and reverse proxy configuration to achieve single-path aliasing. It also highlights considerations for static resources (CSS, JS, PNG) and clarifies the product roadmap status for multi-path routing support.

Here’s how you can configure Joget to work behind a reverse proxy with custom path aliases:

1. Create a Symbolic Link
   Navigate to the Joget Tomcat webapps directory and create symbolic links pointing to the jw folder. This allows Joget to be accessed from multiple alias paths.
   

   # Please refer the command below for linux
   cd /<joget-path>/tomcat/webapps
   ln -s jw engage-qa
   ln -s jw engage-dev
   ls -l   # verify the symlink

   The output should similar to:

   

2. Restart Joget/Tomcat so the newly created aliases are loaded.
3. Update the Nginx Configuration
   Modify the nginx.conf file to define reverse proxy rules for each alias path. Example configuration:
   

   	# other nginx settings up here..
   		server {
   			listen       3000;
   			server_name  localhost;
   
   			underscores_in_headers on;
   
   			location /engage-dev/ {
   				proxy_pass  http://localhost:8080/engage-dev/;
   				proxy_set_header   X-Real-IP        $remote_addr;
   				proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
   				proxy_set_header   X-NginX-Proxy    true;
   				proxy_set_header   X-Forwarded-Proto $scheme;
   				proxy_set_header   Host             $http_host;
   				proxy_set_header   Upgrade          $http_upgrade;
   				proxy_redirect     off;
   				proxy_http_version 1.1;
   				proxy_set_header   Connection "upgrade";
   			}
   
   			location /engage-qa/ {
   				proxy_pass  http://localhost:8080/engage-qa/;
   				proxy_set_header   X-Real-IP        $remote_addr;
   				proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
   				proxy_set_header   X-NginX-Proxy    true;
   				proxy_set_header   X-Forwarded-Proto $scheme;
   				proxy_set_header   Host             $http_host;
   				proxy_set_header   Upgrade          $http_upgrade;
   				proxy_redirect     off;
   				proxy_http_version 1.1;
   				proxy_set_header   Connection "upgrade";
   			}
   
   		}

4. Restart the Nginx service to apply the changes.
5. Verify the Setup, open a browser and test the URL: http://localhost:8080/engage-dev
   The application should load correctly, and the browser URL should remain with the alias /engage-dev instead of showing /jw.
   

Configuring Joget Behind a Reverse Proxy with Nested Path Aliasing

In addition to single path aliases, Joget also supports a method to achieve nested path-style access by using symbolic links. This works by leveraging the behavior where # in a symbolic link name is interpreted as / at runtime.

For example, to enable access through /engage/dev:

cd /<joget-path>/tomcat/webapps
ln -s jw engage#dev

Once the symbolic link is created, Joget can be accessed at: http://localhost:8080/engage/dev

This approach provides greater flexibility when you need to organize multiple environments (such as dev, qa, or uat) under a common parent path.