Wikimedia Developer Support

Help to Host React-apps in toolforge

I’m facing the issue to host the VideoCutTool front-end (React app) in the toolforge. So the front-end is currently hosted in (only front-end).

I found to host the back-end of this app and hosted here

I couldn’t find any documentation to host the react-front-end of this tool in toolforge, I have tried several times but :frowning:

Hey thanks for posting this. I am facing a similar issue. I tried to host a reactjs app with the nodejs server. But it is not a successful attempt ;), and even I could not find any docs related to hosting the reactjs sites. Wondering now if there is any way to host react apps there !!

Haven’t tried myself but doesn’t hosting a client-side app basically just mean putting/symlinking it into public_html?

We only have a node-specific tutorial:, and there isn’t any with React combined.
As per this tutorial, the templates are served from www/js/public/views directory, so I am guessing your React files also need to go here.

What specific issues you are facing while hosting the app? @bd808 or @Chicocvenancio might be able to help here.

1 Like

@bd808, @Chicocvenancio can anyone explain the suitable way for hosting react app over toolforge. Do we need express server for doing the task, or does the build directory works fine ?


1 Like

Thanks @Tgr. This works fine if there are no routes in the app. If there are some routes like: The server is defaulty going to a directory named add (which does not exist) and tries to render index.html file. As there is no file, it returns a 404 page.

But In a react app, for every request ideally the main index.html file generated in build directory has to be returned.

React Apps only really need the build distribution file to be served and correctly referenced to work. So leaving the build files in the correct paths will do, probably can be served from even. Making the build environment is where there are more hurdles with react and Toolforge.

You can control this with your own lighttpd tool if you wish, but that should only affect the initial url to the tool. If the user is coming from the index, the routes should trigger new get requests to the server but be defined in the react app Javascript.

Thanks for the reply!!

Instead of using a custom web server like lighttpd, can I use express and host it as a nodejs app instead ?? (as specified here:

Yeah but In build version of react, whatever the request the client put there need to changes made in index.html file (as per react router is defined). But as I said the web server is searching for the index.html file in the corresponding route.

Sure, start a node10 kubernetes pod and use that to serve it… It is likely lighttpd is more performant and can achieve the rewrite (from whatever that is not on static path to index.html), but if you want to go the pure nodejs route it is possible.

Thanks @Chicocvenancio I think hosting it with lighttpd will be better. Can you provide me with the link or a document for configuring lighttpd so that I can host the build version there ?


the tool is presently hosted at (hosted in public_html i.e build version of react).

The url exists originally. But it is given not found by the tool !!

Thanks @Chicocvenancio for suggesting about lighttpd. I got the app hosted using it. I just need to write some rewrite rules in .lighttpd.conf for that. The only thing I am bothered now is, every time I request a webpage, apart of the requests made by the original tool, there are many other requests with name collect. Is there any way to avoid them?

Those collect requests are to .You can read a bit about it in or maybe @bd808 can elaborate a bit.

I wouldn’t worry about avoiding them, they are mainly to collect info about cross site requests in Toolforge.

@Rammanojpotla See for the sites that requests to your app are loading external resources from and reporting back as Content-Security-Policy violations.

Loading resources (images, css, js, fonts, etc) from non-Wikimedia sites is a soft violation of the Terms of Use for Toolforge and Cloud VPS projects. There is a bit of information at on alternate sources of javascript, fonts, and map titles that can be used by Toolforge tools without forcing your users to interact with 3rd party webservers which may or may not be tracking them.

At some unspecified point in the future the Content-Security-Policy header will be changed from “report-only” mode to being enforced. When that happens loading assets from 3rd party sites will fail rather than issuing a warning to the browser’s console and reporting the violation to the csp-report tool.