The devserver is meant for local development and is not accessible from outside by default.

However, you can adjust this behaviour in vue.config.js with the devServer option.

https://cli.vuejs.org/config/#devserver

Options to look into:

https://webpack.js.org/configuration/dev-server/#devserver-disablehostcheck

https://webpack.js.org/configuration/dev-server/#devserver-host

Thanks for you reply.
Yes, I read that and have already tried; if my understanding is correct, that means putting this file?
It was not effective.
App cannot be accessed via domain (Invalid Host header), and even if I somehow connect (e.g. using global IP address) HMR fails because vue-cli-service thinks local address as global.
Also the console shows "App running at: Local: localhost:8080 Network: xxx.xxx.xxx.xxx:8080" where xxx.xxx.xxx.xxx is local IP address (I think this is meaningless).

the devServer options have their own options property in vue.config.js because we process them internally before handing them to the devserver:

module.exports = {
  configureWebpack: {
    // other webpack options to merge in ...
  },
  // devServer Options don't belong into `configureWebpack`
  devServer: {
    host: '0.0.0.0',
    hot: true,
    disableHostCheck: true,
  },
};

Oops, my fault... thanks for pointing out.
But still, two other problems persist.
I think address.ip() used here is something meant to get local IP address, unlike other things like this and this?

• Local IP address is shown in console
• HMR fails because sockjs tries to connect to local IP address
• App cannot be accessed from outside the network, so I have to use tricks like ssh port forwarding

The code you mention should not be running if I set the host option (to your external IP)

So you mean the right configuration is not host: '0.0.0.0', but host: 'ggg.ggg.ggg.ggg', where ggg.ggg.ggg.ggg is my global IP address, right?
It also didn't work (of course no other process is listening to 8080, just to make it clear):

$ npm run serve

> anne3@0.1.0 serve /***/***/***/***
> vue-cli-service serve

 INFO  Starting development server...
Starting type checking service...
Using 1 worker with 2048MB memory limit
 10% building modules 1/1 modules 0 activeevents.js:183                            
      throw er; // Unhandled 'error' event
      ^

Error: listen EADDRNOTAVAIL ggg.ggg.ggg.ggg:8080
    at Object._errnoException (util.js:992:11)
    at _exceptionWithHostPort (util.js:1014:20)
    at Server.setupListenHandle [as _listen2] (net.js:1338:19)
    at listenInCluster (net.js:1396:12)
    at GetAddrInfoReqWrap.doListen [as callback] (net.js:1505:7)
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:97:10)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! anne3@0.1.0 serve: `vue-cli-service serve`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the anne3@0.1.0 serve script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/ec2-user/.npm/_logs/2018-06-21T07_43_06_386Z-debug.log

Hm, I see...

Side question: why do you want to run the development server on a remote machine?

Well, I thought that occurs everywhere... at least in the companies I have been at :)
Manager gives an EC2 instance to each developer, and they do their development on that machine.
This way provisioning is easy and you can destroy and rebuild machines at any time.
Plus you can limit resource access (e.g. RDB) within the network (on the cloud).
Another good point is I usually use my Windows PC but can develop on Linux.

Out of curiosity, when you develop on localhost, then I wonder why HMR wants to connect to the server via local network address, not localhost.

I think setting devServer.public to 0.0.0.0 is a misconfiguration. The linked docs say:

When using inline mode and you're proxying dev-server, the inline client script does not always know where to connect to. It will try to guess the URL of the server based on window.location, but if that fails you'll need to use this.

Based on my testing, the address given for devServer.public is what the (browser) client will use when attempting to open a websocket connection for HMR. So if you set it to 0.0.0.0 it won't be able to open the websocket because that's not a routable IP.

Something that can be confusing is the auto-detection can end up using an IP from a purely local network adapter. For example, the yarn serve defaults give me:

App running at:
  - Local:   http://localhost:8080/
  - Network: http://10.0.75.1:8080/

That 10.0.75.1 IP is for DockerNAT. It's only accessible from my machine. I've always thought you can bind to localhost and 0.0.0.0 reliably and beyond that you need user specific config. Where does the 10.0.75.1 get detected?

The Network IP (10.0.75.1) is the same IP that is used (by default) for the HMR websocket for me. Where is that default getting set? If vue-cli-service serve is setting it, I don't think it should. The window.location strategy described in the Webpack docs seems like the most reliable way to do it. If that doesn't work, I can't think of a way you'd be able to figure it out (reliably) without having the user specify it. Is there another way?

What exactly is the Network address being reported? When I set devServer.public to an alternate IP, the HMR websocket connection uses the newly set IP (as expected), but yarn serve still reports Network: http://10.0.75.1:8080/.

It also seems like the server binds to 0.0.0.0 even though the above App running at message gives the impression it bound to 2 specific interfaces. By default, I can access the server from another PC on my LAN. If I set devServer.host to 0.0.0.0, there's no change:

// vue.config.js
module.exports = {
    devServer: {
        host: '0.0.0.0',
    },
}

gives:

App running at:
  - Local:   http://localhost:8080/
  - Network: http://10.0.75.1:8080/

The app is still accessible from my LAN. If I set devServer.host to localhost something doesn't like it:

App running at:
  - Local:   http://localhost:8080/
  - Network: undefined

However, the app is only accessible at localhost which makes sense since I set host to localhost.

Is the goal to avoid giving the user http://0.0.0.0:8080 as an address? If so, maybe you could do something like this (ignoring https options):

Server listening at:
- Host: devServer.host
- Port: devServer.port

Then, if devServer.host is 0.0.0.0 (this always includes localhost):

App available at:
- Local:  http://localhost:devServer.port
- Public: devServer.public or 'None'
See: https://webpack.js.org/configuration/dev-server/#devserver-public

Otherwise:

App available at:
- Local:  http://devServer.host:devServer.port
- Public: devServer.public or 'None'
See: https://webpack.js.org/configuration/dev-server/#devserver-public

The --public option described in the Webpack Docs doesn't seem to pass through on the CLI. Is it supposed to? Ideally the OPs case would be solved by (note: this does not work currently):

yarn serve --host "0.0.0.0" --port "8080" --public "mydomain.example.com:8080"

with the output:

Server listening at:
- Host: 0.0.0.0
- Port: 8080

App available at:
- Local:  http://localhost:8080
- Public: http://mydomain.example.com:8080
See: https://webpack.js.org/configuration/dev-server/#devserver-public

@kissge Try this vue.config.js:

// vue.config.js
module.exports = {
    devServer: {
        host: '0.0.0.0',
        port: '8080',
        public: 'mydomain.example.com:8080',
    },
}

Note that you must be able to connect to mydomain.example.com on port 8080.

@LinusBorg A decent use case for wanting to do this is to have a site / app running on an alternate device during development. For example, at the moment I'm playing around with an app on a Raspberry Pi. The screen is fairly low resolution (800x480), the color reproduction isn't comparable to the monitor I use for development, and I want to test the touch input. It's useful to have it plugged in beside me auto-reloading as I make changes.

@ryanjaeb You can use my patch/workarround to solve this issue, look here #1905

So, the inference for public network API has its limitations, but you can always explicitly specify the public URL to use with devServer.public in vue.config.js.

In ccc90c9 I've also added:

• allow specifying devServer public url via vue-cli-service serve --public your/url:port
• made the console message prioritize this value.