Local 5.x how to check site remote host and port

How can I get the remote port and host in the new Local version 5+?. I used Local by Flywheel 3.0.5 and downloaded the new Local, but I need to know Local sites remote host and ports. In the older Local by Flywheel remote host and port were clearly visible in the sites “Database” tab, but in the new Local they are missing. I need the remote host and port for my custom script which is used to get site from a live server to Local.

1 Like

Using Sequel Pro I was able to connect to the database by switching to the “Socket” tab in the connection details and pasting in the full path that Local provides for the socket information found under the “Database” tab in Local.

For example on macOS: /Users/YOUR_USERNAME/Library/Application Support/Local/run/ApnsZz3sB/mysql/mysqld.sock.. The ApnsZz3sB part of the path is unique per site and is what needs to be changed for a new connection.

Hope this helps!

The information about the socket connection for the database is useful. I’m trying to use the wp cli locally to manage a site, but I think I need to know the remote host and port to do that. https://salferrarello.com/wp-cli-local-by-flywheel-without-ssh/

Have you tried this?

Hi @afragen thanks for the response. The issue in this thread is that we need to know the values of “Remote Host” and “Remote Port”, which used to be visible in previous versions of Local. Will symlinking the socket file make those values visible?

You might need to switch to localhost in the router preferences.

I tried switching to localhost, and restarting Local, but the Remote Host and Remote Port still don’t display.

Hmm, I’m guessing Flywheel has changed how they access the database. It now appears only accessible via a socket.

That breaks a lot of development workflows. There must be some way to connect without the socket.

1 Like

For example, the WordPress CLI doesn’t seem to support connecting to the database via sockets https://make.wordpress.org/cli/handbook/?s=socket

@localjo what WP-CLI commands aren’t working for you?

Any and all WP CLI commands are telling me that there is an error connecting to the database when I try to run them from my local machine, and my preferred terminal (VS Code) rather than SSH, because I don’t have the “Remote Host” and “Remote Port” values needed to configure WP CLI with wp-cli.local.yml so that it can connect to the database. https://make.wordpress.org/cli/handbook/config/#config-files

@localjo can you share a screenshot of the actual CLI error?

There is likely a difference between there’s an error running the wp-cli commands in the manner I’m running them and there’s an error running the wp-cli commands under all circumstances.

It may be that your workflow doesn’t work any more. I’m not familiar to configuring via wp-cli.local.yml. If the commands work in Open Site Shell then the problem is the how your workflow is setting the environment variables.

Is it possible that using the wp-cli.local.yml is specific to running a virtualized environment.

Where are you saving the file and are you certain WP-CLI is seeing it?

Check with wp version --debug

I don’t have a wp-cli.local.yml file and this is part of my output.

Debug (bootstrap): Using global config from WP_CLI_CONFIG_PATH env var: /Applications/Local Beta.app/Contents/Resources/extraResources/bin/wp-cli/bin/config.yaml (0.25s)

Debug (bootstrap): No project config found (0.25s)

I’m running the commands in the normal way, and the error is verbatim what I already said:

Screen Shot 2020-04-24 at 9.15.07 PM Screen Shot 2020-04-24 at 9.15.26 PM Screen Shot 2020-04-24 at 9.15.46 PM

That’s why I posted this link: Config – WP-CLI – WordPress.org

If the commands work in Open Site Shell then the problem is the how your workflow is setting the environment variables.

Yes, that’s the point of this thread. I don’t have the information needed to set the variables correctly because Local isn’t showing that information.

If you know how I can extract this information, have information from the Local development team about why it was removed, or know how I can file a bug report, that would be helpful.

The site environment variables are set in the initial lines of the Open Site Shell command. You should be able to see the bash script used.

My guess is that in the switch from VirtualBox to a non-virtualized environment this changed .

Windows versions of Local still use ports, but Mac and Linux make use of sockets. If you are using those systems, then you won’t be able to connect via ports.

When clicking the “Open Site Shell” button, all that is happening is that a script is being called that sets up various environmental configuration options and appends php, mysql, and wp-cli to the shell’s path.

Because of this, if you have a Posix style shell, you should be able to get the correct environment working by running that script.

@localjo – for your use case within VSCode’s terminal it’s as easy as that. You can:

  1. Open site shell from Local
  2. Note the script that is called
  3. Run the script within VSCode’s terminal


There are countless wordpress tools, plugins, and workflows that require simply connecting to the DB through a remote port. Why was the decision made to remove the ability to use all of those plugins and tools in the latest version of Local? For example: the duplicator plugin, which lets me duplicate my live site to my local dev environment, requires remote ports. because of this, i will never be able to use lightning.

1 Like

Thank you Ben! I somehow missed that command being printed to the terminal. It’s very helpful that you pointed it out! This works great.


1 Like

The main reason to use sockets and not ports for connecting to the Local database is due to performance reasons. The reason that previous versions of Local made use of Ports is because each WordPress site was contained within a virtualized environment – from the point of view of the Host computer, each WordPress site was a “remote host”, and the only way to connect to the database was through an exposed port.

It’s important to note that many of these kinds of plugins will still work in the same way that they worked with Local Classic.

In the case of the duplicator plugin, unless you were doing some really fancy network proxying (at least I think it can be done, I’ve never tried it ¯_(ツ)_/¯), only the Local site could connect to the remote site. The remote site would not be able to connect to the port of the Local site – it wouldn’t know how to reach your Local site due to the way that DNS works.

If the remote site exposes the database for you to connect to, then in Lightning, you should still be able to connect to the remote port of the remote site, and use the duplicator plugin.