Running multiple expo app at the same time on different ports

Hi! I remember being able to run multiple expo apps at the same time on my laptop. I am working on two apps simultaneously and for testing purpose i need to be able to run them at the same time via Expo-cli.
But since couple of days now I cannot do that. I’ve tried changing the port number in the.exop/packager-info.json. But the second app lauch keeps failing whit the following error.

So what I wanted to know is if it is possible two specify the running ports for expo so that my to apps can run simultaneously on my computer without any interference

I don’t have to do anything for this to work. If I just run expo start in two different terminals at the same time they automatically start up on different ports.

In the first terminal I get something like this:

Expo DevTools is running at http://localhost:19002
Press d to open DevTools now, or shift-d to always open it automatically.
Starting Metro Bundler on port 19001.
Tunnel ready.


and in the second I get something like this:

Expo DevTools is running at http://localhost:19003
Press d to open DevTools now, or shift-d to always open it automatically.
Starting Metro Bundler on port 19005.
Tunnel ready.


They both show up in the “RECENTLY IN DEVELOPMENT” list in the Expo app and I can open them both up and have them running at the same time.

I’m running expo-cli version 3.2.3.

I have same issues, but in port 19002

What version of expo-cli are you running?
What exactly happens when you try to run two instances of expo start in two separate terminal windows?

Hi @wodin I am using the latest (same version as you). Here is a screenshot of the result I have. App A (a the left) runs fine but I cannot run App 2 (at the right) at the same time. I have an Address already in use error . Edit: I’ m working on Mac

hmmm… when I tried this yesterday it was on a Linux machine, where it worked perfectly. I’ve just tried it on a Mac now and I am getting the same behaviour as you.

It used to work on mac for me too but since couple days (Cannot say exactly when it stop working) I cannot do it.

I’m not sure why it’s picking a port that’s already in use, but it looks like something related to your system. For me, the Metro bundlers are all started on 19001, but I’m not sure if that’s just me or intended behavior.

However, if you really need to start separate processes, including Metro, you might be better off to contain them in docker containers. It’s not super hard, and they are fully isolated from each other.

You can do that by running this docker command (using this image):

$ docker run -ti \
    -w /code \
    -v $PWD:/code \
    -v /code/.expo \
    bycedric/expo-cli:3 start --tunnel

Basically, the -w defines the working directory in the container. The -v $PWD defines the volume to mount from host to the container (this is where your code is ported to the container; it should update on every change). You also need to avoid the .expo folder being shared as it contains information about the processes (which we want to isolate), that’s happening in -v /code/.expo (it creates a new volume over the existing one). And finally, you can start Expo in tunnel mode to avoid having to worry about all port forwarding and limitations.

I hope this helps a bit!

1 Like

It looks like a bug/quirk in the freeport-async package.

If I run expo start for one app I get the following on my Mac:

$ netstat -p tcp -an | grep 1900[0-9].*LISTEN
tcp46      0      0  *.19001                *.*                    LISTEN     
tcp46      0      0  *.19000                *.*                    LISTEN     
tcp4       0      0        *.*                    LISTEN     

If I then run the following code, it tells me that the next free port is 19002:

var freeportAsync = require('freeport-async');
freeportAsync(19000).then(port => {

expo-cli is using freeport-async to find available ports.

On Linux, however, I get the following:

$ netstat -tln | grep 1900[0-9]
tcp        0      0*               LISTEN     
tcp6       0      0 :::19000                :::*                    LISTEN     
tcp6       0      0 :::19001                :::*                    LISTEN     
$ node index.js 

It’s nice to keep the ports in a similar range, but not really necessary for most of them if you ask me. So the code could possibly use one of the other methods mentioned here.

Alternatively, maybe this fork of freeport-async would help. Then they would be able to specify the IP address as well which I think might solve the problem.

@ccheever, I see most of the commits to GitHub - expo/freeport-async: Uses mikeal's code to find an open port in a given range are yours :slight_smile: What do you think of some changes to freeport-async?

I use window 10 and using latest expo-cli (3.2.3). I still confuses how to solve this issue.

@fson has created a bug for this, so it will probably be fixed in the next version of expo-cli:

fson commented 20 hours ago

Starting two instances of Expo CLI results in the following error, because the Dev Tools is listening on localhost and therefore ignored by our free port detection.

There’s a PR in expo/freeport-async#3 to address this.

Expo CLI 3.4.0 was released today and it includes a fix to this bug.

1 Like

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.