Let all your devices see your site

Today’s subject may seem a niche-ish use case, but I have reason to believe otherwise.

Let’s say you’re developing your website. Since you want to make sure it looks okay on other operating systems, too, you may be using either a virtual machine (like Parallels Desktop, the appropriate VMWare product, or VirtualBox) or an actual second computer running one or more different OSs. Or, for that matter, you’re equally concerned with how the site looks on a phone or tablet, and you’re not willing to depend on your browser’s emulation mode for determining that—and, by the way, you’re wise to think that way.

In short, you want to test your site locally on more than just your dev machine, while in dev mode.

In such cases, you need to make it possible for those other devices to “see” the website’s local dev server running on the dev machine’s localhost instance. What to do?

Find that address

The answer is to point your other devices to the dev machine’s IP address on your LAN. That will enable those devices to access your machine’s localhost instance through a URL in the following format:

http://[IP address]:[port number]

For example: if your dev machine’s IP address is 192.168.254.10 and your chosen dev method uses port 3000, your devices can access the project via http://192.168.254.10:3000. As for the port, I’ll get into that below for each static site generator (SSG) or other project type we’ll be discussing.

Now, let’s walk through how you discover that address.

macOS

On a Mac, go into your chosen terminal app and enter:

ifconfig | grep broadcast

. . . and you'll see one or more lines like this:

inet 192.168.254.10 netmask 0xffffff00 broadcast 192.168.254.255

The address you want is the one immediately after inet. (If you get multiple inet lines, you can use any address immediately following inet in a line.)

Windows

In Windows, open the Command Prompt and enter this into the resulting screen:

ipconfig

In the resulting display, you’ll get the desired address from a line that begins with IPv4 Address, like this:

IPv4 Address. . . . . . . . . . . : 192.168.1.49

Linux

On Linux, you have multiple choices (wouldn’t you know?), but the easiest is to enter this in your terminal app:

hostname -I

. . . which reports the IP address.

Tell ’em where to go

Now you have to set your project’s dev server to use that IP address, rather than just localhost. Even if a platform already uses the IP address (likely displaying it for your convenience) when you run it in dev mode, you may want to change the port for some reason, so we’ll discuss that, too.

Eleventy

If you’re using a pre-version-2.x version of the Eleventy SSG, its Browsersync dependency will, by default, display the correct IP address when you run Eleventy in dev mode. In Eleventy 2.x and above, its built-in dev server doesn’t do that by default but you can edit its settings in the .eleventy.js config file so that it will, by adding a line saying showAllHosts: true (the showAllHosts default setting is false).

By default, Eleventy’s dev server uses port 8080. If you prefer to use a different port, either set it in .eleventy.js (in Browsersync with pre-2.x or the built-in server with 2.x+) or, when running the eleventy command, use the --port flag as shown here, wherein you’re specifying port 3000:

npx @11ty/eleventy --serve --port=3000

(The --serve flag keeps Eleventy watching for changes while you work on your project.)

Hugo

With the Hugo SSG, you’ll want to add the --bind and --baseURL flags to the usual hugo server command. Using our example IP address (and Hugo's default dev port, 1313) you’d do it this way:

hugo server --bind=0.0.0.0 --baseURL=http://192.168.254.10:1313

To change the port number from the default, you must add a -p or --port flag and change the --baseURL flag accordingly. So, to use port 3000 rather than port 1313, you'd enter:

hugo server --port 3000 --bind=0.0.0.0 --baseURL=http://192.168.254.10:3000

(You can’t change the port by simply changing the --baseURL value; you must also use the -p or --port flag.)

Astro

With the Astro SSG, use the --host flag with astro dev; e.g.:

astro dev --host 192.168.254.10

By default, it’ll use port 3000, but you can change that by adding the --port flag. You also can set these parameters in the project’s astro.config.mjs file.

Next.js

If you’re running Next.js, use the -H flag with npx next dev to set the hostname to the desired IP address. To use a different port from the default of 3000, use either the -p flag or the PORT environment variable—PORT=3000, for example—but the latter cannot be set in a project’s .env file. You also can set these parameters in the project’s next.config.js file.

Gatsby

When using Gatsby, use the -H or --host flag with gatsby serve to set the hostname to the desired IP address. To change the port from the default of 9000, use the -p or --port flag.

Nuxt.js

With Nuxt.js, use the HOST and (if desired) PORT environment variables with npm run dev as follows, using our example from above (changing the port here, too, from its default of 3000):

HOST=192.168.254.10 PORT=8000 npm run dev

The documentation advises against using the site’s config file to handle these settings.

Jekyll

Using Jekyll? Use either the -H or --host flag with jekyll serve to set the hostname to the desired IP address. To change the port from the default of 4000, use either the -P or --port flag. You also can set these parameters in the project’s configuration file (_config.yml or _config.toml).

With Live Server on VS Code

For you folks who prefer to hand-code without help from SSGs, here’s how you'd make the aforementioned settings in the popular Live Server extension for Visual Studio Code:

• To set the hostname to the desired IP address, use liveServer.settings.host (the default is 127.0.0.1).
• To set the port, use liveServer.settings.port (the default is 5500).

Stick to the script

Finally, on SSGs, I suggest handling these changes via shell scripts. I can assure you that I do not do this stuff without them. For example, here’s the start shell script I run when developing in Hugo:

#!/bin/sh

rm -rf public
hugo server --port 3000 --bind=0.0.0.0 --baseURL=http://192.168.254.10:3000 --buildFuture --panicOnWarning --disableFastRender --forceSyncStatic --gc

Just entering ./start.sh into my terminal app is far easier than always keeping a tab open to the appropriate hugo server documentation, much less re-entering all that jazz every time I run hugo server.

Of course, with projects that use scripts in package.json, it might be as simple as remembering to use npm run start or npm run dev, assuming you've edited your start or dev scripting to include the specifications we've discussed in this post. Still: if you jump back and forth among projects and they don’t all use package.json, you can always make the most of your muscle memory by putting a start shell script on each project—even if, in the case of a package.json-using project, the script’s only content is npm run start.¹

Image credit: Fotis Fotopoulos; Unsplash

1. Plus, your terminal app should remember it for you, anyway. While, sure, that also could re-run one of the longish commands I mentioned, I still encourage using shell scripts just so you won't have to keep cycling through so many different sets of commands in your terminal app’s memory. ↩