Confused about interface_config.js

Hi folks. I am using “make dev” to run my local server and experiment with GUI changes, but something odd (to this newbie) is happening. I have added a new mode and button following the model of how Tile View is implemented, but it doesn’t show up.

I tracked it down to needing to be included in interface_config.js array of TOOLBAR_BUTTONS but oddly no matter how I edit that it doesn’t seem to change what is actually loaded into the object.

What part of the dev architecture am I getting wrong? Is this overwritten or included from somewhere else that I don’t see?


Configuration files are coming from the server.

Thanks @damencho. I’m finally starting to understand that, and found this discussion from a few months back:

It feels like a really odd workflow for those of us who are not interested in developing any backend stuff, and love the fact that webkit provides a nice local server for us to use that integrates with for the backend. The problem is for ‘frontend’ stuff like UI, it now requires our own dev server just to make tiny changes to .css or config files. Is there no way to configure the webkit so it grabs those files locally as well?

In my case I have created an entirely new view like “tile view” and want to test it, but merely because I can’t add my button to TOOLBAR_BUTTONS in interfaceConfig.js it won’t load. I can hack it by replacing existing functionality that is configured automatically, but that sort of defeats the purpose of the config files.

See the problem? Any thoughts on this? Am I missing something fundamental about why the backend server needs to serve these config and HTML files instead of the local one?

Thanks a million. Jitsi is really, really amazing.

Further to this, it looks like there could be some sort of workaround for people in my situation who want to experiment entirely locally (except the backend of course):

  • It looks like we could set up our own version of interface_config_local.js and import it, maybe with a different name, in the modules where we would like to use it (ie toolbox.js)
  • It looks like there is some business around adding overriding configs to the hash part of the URI - perhaps we can take advantage of that? (from comment in setConfig() function within actions.js)
  • other, simpler idea?..

Of these hacks, would you recommend one or the other for simple, reversible changes to eg: TOOLBOX_BUTTONS array or trivial tests like APP_NAME? Which has more integrity with the overall architecture of the project?

Bu default jitsi-meet includes in index.html using ssi the interface_config and config. So one workaround is to make webpack serve a local copy of index.html where you include those config js files as usual (not ssi as there is no such on webapck level) and this way you can serve the local copies, but you need to make sure config js is always and up to date version of the one taken from

THX will try this - I see it is two changes:

  • add /index.html to the devServerProxyBypass in webpack.config.js
  • modify /index.html to remove <!–#include virtual… (?) so the local file gets included

Will let you know if this works. Thanks for the tip about making sure to (manually) make sure config is sync’d with the alpha version.

Really appreciate your help.

OK sorry to keep bugging you, & I’ll step away from this for a bit, but I’m having trouble with your first suggestion - “make webpack serve a local copy of index.html”. I thought this would be possible by adding it to the devServerProxyBypass() call, but it still seems I am hitting’s version.

Web searches on webpack are only confusing me more on this one.

Oh wait - I think it is actually working; just that when I enter a conference name in the URL instead of exactly “localhost:8080/index.html” it doesn’t bypass and loads the server-side one. I think I can probably work with this.

Thanks again for your help, making slow progress, will update once I finally succeed!


Yes, it finally worked! As long as I added both /index.html and /interface_config.js to the devServerProxyBypass() call. AND, only works for the conference named ‘index html’ - hillariously. Due to the server using the conference name as the URL. That’s totally fine with me for now though, so I can move on to testing things without spinning up my own server.

Thank you so much for these insights and your help.

@artknight FYI, this is a (workable-for-now) solution to the issue you raised a month ago.

For anyone looking to reproduce what worked for me:

  • npm install
  • make dev

Will get you a server running on https://localhost:8080

Check that this is working for you. You should now be able to make edits such as changing the text under “appDescription” in /lang/main.json and you should see that reflected on the main page. Be sure that’s working before you proceed.

Now, any changes you make to .js code should be visible in your localhost server. However, changes to .css, .html, and the toplevel config.js and inteface_config.js (among others??) won’t work because you are acquiring those files from the remote server (

You can address this by changing the file webpack.config.js. Look for the function devServerProxyBypass(). Edit it to add:

|| path.startsWith('/index.html')
|| path.startsWith('/interface_config.js')

and any other files that you know you want to be served from your local server instead of the backend server. This will tell webpack to bypass getting them from - as long as they are called directly. (Thanks @gpatel-fr for this hint)

Now, within index.html, you need to change the lines at the end that include any .js file to be served locally instead of virtually (I think??) for example, from:

<script><!--#include virtual="/interface_config.js" --></script>
<script src="/interface_config.js"></script>

While you’re editing index.html, add something specific to your local version so you’ll know it’s working. For example, I changed line 31 to output “(local – TIME) index.html loaded:\t” so that looking at the console I’d know if I was loading the local version or the remote one.

Now you should be all set. Make another simple change to interface_config.js, for example edit the APP_NAME to say “Jitsi Meet - local” and see if that is how it now refers to itself in the browser tabs.

This all worked for me, as long as I specifically loaded
https://localhost:8080/index.html in my browser tab. Note, it doesn’t work if I don’t put in the /index.html part. And if I put anything else, including the name of any meeting other than “index.html” it will still load the remote version. But for my experimental purposes, it doesn’t matter because I am just meeting with myself at this point to try out new interface paradigms.

Finally - picking up on what @damencho said above, the config.js file on is significantly different than the one in the repo you’ve downloaded. You should make a backup of yours then replace it with the code from, so that you are working properly with the alpha server that the nice jitsi folks have provided.

Finally, do all of this at your own risk and your mileage may vary – it is working for me for now, but it does feel like a bit of a hack. Thanks to @damencho and also to @artknight and @gpatel-fr for your breadcrumbs from the thread linked above.

@Apoorv_Jain, since you asked - here are the directions. Let me know if it works for you.

Hm… I just had a thought - if lots of people start following these instructions, will we all establish meetings on called “index html” ?? And if so, will we all be suddenly meeting with one another? I guess we’ll find out! :laughing:

Thanks a lot !

I had the same issue as OP and took a slightly different approach. I wrote an extended blog post about it here which may or may not be of use to you depending on your particular deployment. Basically, I’ve wired up my custom front end to a local back-end instance running in a Docker container, and then do a container rebuild each time I make any changes to files that touch the back end. I’ve just put together a basic bash script to do the rebuild itself, takes around 40 seconds on my machine.

1 Like

Thanks @alexclaydon! Super-useful and likely where I’ll go once I outgrow my little experimental UI sandbox that I achieved above. I’m bookmarking your instructions and going to need to learn a lot more about the back-end, or hire someone, if what I’m doing starts to look promising.