Docker: expose default port of webapi container


why the default port 8080 is not exposed to the docker host?

If i use:


- “8080”

i can use the IP of the dockerhost (MYDOCKERHOST) and this fits with the documentation:
If not, i must find out the IP of the docker container first.

I think exposing the default port 8080 makes sense, as with this additional config the docker setup runs nearly out of the box and fits requiremet of most users. Users who wanna change ports, will be aware of that anyway. Furthermore i don’t think that many users will change the 8080 port of the webapi tomcat.

I did a pull request for that.

Kind regards



Usually there is no need for regular users to directly connect to the API-Port.

The users browser connects to the webui exposed port (default either 80/TCP or 443/TCP) which then also proxies API requests to the webapi container internally.
Check ./metasfresh-docker/webui/sources/configs/metasfresh_webui.conf if you want to know what is proxied to the webapi container.

And since the webui container is the one exposed to the dockerhost all necessary calls for general users are available using http://your-docker-server/.../.

That way, only the most necessary ports are exposed to the dockerhost which in return provides admins less maintenance/firewall-rules/port-conflicts to run a metasfresh-docker stack in their environment.

However, if you want to access the API directly for reasons of developing or debugging, you’re free to expose the port 8080 on your system just as you described in your post.

You can then backup your docker-compose.yml to a different directory before updating to a new release of metasfresh with git pull and put the docker-compose.yml file back in place before building the new images.
Just make sure to compare the latest docker-compose.yml to your modified one so you can integrate possible changes (ie. additions of new docker-containers to the metasfresh-stack like the recent addition of elasticsearch ).

If something’s not clear or if you have additional questions, feel free to ask.


thanks for your answer. I agree mostly with everything you say.

With “ports” you expose the ports 80 and 443 of the webui to the docker host and localhost. But this is not what i want to do with the webapi. There i want to use “expose” in order to just forward the port from the container to the main docker ip.

Now i have: my main docker IP (let’s call that dockerhost IP whch is different from my localhost IP) and my IP on my webapi container

in the doc
it says:


which implies to use, but this will not work without the “expose 8080”. Without expose 8080, it works only if i put the IP of the docker webapi container into the config.js.

In order to use (MYDOCKERHOST) in the config.js file, the webapi port 8080 must be forwarded by “expose 8080”. Then port then will not be forwarded to localhost, only to the dockerhost and the documentation fits.

Kind regards



in the part of the documentation where it says: replace "MYDOCKERHOST:PORT" you should replace MYDOCKERHOST with the hostname/IP-Address where your client’s browsers are able to reach the metasfresh webui and PORT should be replaced by the portnumber your client’s browsers will connect to the webui.

As an example, let’s assume you have a Server/VM running where you want to host the metasfresh-stack using docker.
The hostname of your server where you installed docker and docker-compose is: myprivateserver
The IP address of the eth0 adapter that you want to host the stack is:
You don’t have a SSL certificate so you’re using the default http-port: 80/TCP

You should replace MYDOCKERHOST:PORT with either:
Your browser is then able to access the metasfresh-stack using either:

In general you shouldn’t use the IP-Addresses docker assigns to the containers, since it may vary (think of having 5 different metasfresh-docker stacks on the SAME server/VM ).
Instead, use the IP address of your server/VM and change the port for the webui container as described here.

A different example:
you want to host 3 metasfresh-docker-stacks on the same machine (server/VM) with following specifications:
Hostname of your server/VM: myprivateserver
IP-Adress of your server/VM:
Port-Range you want to use the browsers to connect to: 8181-8183

The first stack would use these settings:

    - "8181:80"


const config = {
        API_URL: 'http://myprivateserver:8181/rest/api',
        WS_URL: 'http://myprivateserver:8181/stomp'

The second stack would have a config like this:

    - "8182:80"


const config = {
        API_URL: 'http://myprivateserver:8182/rest/api',
        WS_URL: 'http://myprivateserver:8182/stomp'

and so on…

So if your clients should use the first metasfresh-stack to work with, their browser-url should be:
For the clients who should access the second stack, the should type http://myprivateserver:8182 in the URL-bar of their browsers.
There is no need to expose port webapi:8080/TCP at all!

And as I wrote in my post above:
You might want to expose the webapi-port directly but that would only be for developing and debugging.
And even then, you should use the IP of your physical adapter of the server (eg.: eth0) to connect to the webapi-instance and instead of using the docker-container IP, you should alternate exposed ports.



the apache acts as proxy to the webapi, so the client’s browser not have to request the webapi directly


thanks for clarification @julian.bischof for now it is clear to me…
—> there the webapi port 8080 is exposed even with “ports” :slight_smile:
but as missing elasticsearch and postgresql port is also exposed there, i think this file is not maintained at the moment.

Kind regards

The webui-apache-config is acting as both a proxy and for serving the webui js files.

You’re free to modify/expand/restrict/experiment specific api-requests by modifying ./webui/sources/configs/metasfresh_webui.conf for http-requests and ./webui/sources/configs/metasfresh_webui_ssl.conf if you provided a SSL-Certificate.

Yes, the file is currently not maintained since most users use docker-compose v1 files.
But good point - we should update the “v2” file as well for users who use this version and add an additional “v3” file (docker-compose seem to change their file-versions very often).


better throw v2 away and maintain only one file :slight_smile: so others will not get confused with different configurations (i speak with experience hahaha)

I think to complicated i guess… i have no idea how to describe it better in the documentation:
maybe add a note that only the webui must be accessable from outside?

1 Like