skip to content

What do the Angular CLI's `ng serve` options `host`, `port` and `ssl` control, and what do you change to open the dev server from another device?

level: juniorimportance: should knowfreq 40%

answer

  1. localhost is loopback only
  2. 4200 unless told otherwise
  3. all interfaces with 0.0.0.0
  4. self-signed when no key pair

basics

~20 s

host sets the interface the dev server listens on (default localhost), port its port (default 4200), and ssl switches to HTTPS. To reach it from a phone, listen on 0.0.0.0 and open the machine's address; add allowedHosts for custom hostnames.

solid answer

~40 s

`@angular/build:dev-server` listens on `host: "localhost"` and `port: 4200` by default, over plain HTTP (`ssl: false`). `localhost` binds only the loopback interface, so another device on the network cannot connect; `ng serve --host 0.0.0.0` listens on all interfaces, and the phone then opens `http://<your-ip>:4200`. When you reach it through a hostname other than localhost, such as a tunnel or a `.local` name, list that name in `allowedHosts`, which defaults to an empty list; setting it to `true` allows every host and the schema calls that a security risk. `--ssl` serves HTTPS; with `sslKey` and `sslCert` it uses your certificate, otherwise it generates a self-signed one that browsers warn about. If 4200 is taken, pass another number, e.g. `--port 4300`.

code

bash · 2 lines
bash
ng serve --host 0.0.0.0 --port 4300
ng serve --ssl --ssl-key certs/dev.key --ssl-cert certs/dev.crt

go deeper

for a junior

Recall the defaults: localhost, port 4200, plain HTTP, and the flags that change each of them.

for a middle

Explain loopback versus all interfaces, what allowedHosts protects against, and how ssl behaves with and without a key pair.

for a senior

Show safe team habits: per-project ports, trusted local certificates, and never disabling the host check in shared config.

for a principal

Weigh device testing on a local network against shared preview environments for the team's feedback loop.

## The three options and their defaults `ng serve` runs the builder configured for the project's `serve` target, by default `@angular/build:dev-server`. Its network options: | Option | Default | Effect | |---|---|---| | `host` | `localhost` | the network interface the server binds to | | `port` | `4200` | the TCP port | | `ssl` | `false` | serve over HTTPS instead of HTTP | | `sslKey`, `sslCert` | none | paths to your own key and certificate for `ssl` | | `allowedHosts` | `[]` | host names the server will answer for beyond the defaults | | `open` | `false` | open the default browser on start | Each can be set in `angular.json` under the `serve` target's `options` or passed as a flag: `--host`, `--port`, `--ssl`, `--ssl-key`, `--ssl-cert`, `--allowed-hosts`, `--open`. ## Reaching the dev server from another device `localhost` resolves to the **loopback interface**, which only the same machine can reach. A phone on the same Wi-Fi therefore cannot connect, however the URL is typed. To test on a real device: 1. Start with `ng serve --host 0.0.0.0`, which binds all network interfaces. 2. Find the development machine's LAN address and open `http://<that-address>:4200` on the phone. 3. If you reach the server through a **host name** rather than an address, for example a local network name or a tunnel URL, add it to `allowedHosts`, or the dev server may refuse the request. 4. Allow the port through the machine's firewall if needed. `allowedHosts` is a host-name allowlist that the Angular builder passes to Vite's option of the same name. It accepts a list of names or `true`; the builder's schema describes `true`, allowing every host, as "not recommended and a security risk". Prefer listing the one name you need. Binding `0.0.0.0` exposes your unoptimized development build to everyone on that network, so do it on a trusted network and stop the server afterwards. ## Serving over HTTPS Some browser features are only available in a **secure context**, and some backends set cookies only over HTTPS. `ng serve --ssl` switches the dev server to HTTPS: - with `--ssl-key` and `--ssl-cert` it uses your key pair, for example one issued by a locally trusted development CA, which avoids browser warnings; - without them it generates a **self-signed certificate** on the fly, which works but makes the browser show a certificate warning you must accept. When the page is HTTPS and the backend is plain HTTP, route API calls through the proxy file so the browser does not block mixed content. ## Changing the port If `4200` is taken, `ng serve --port 4300` or a `port` value in `angular.json` picks another one. Teams running several apps side by side usually set distinct ports per project in `angular.json` so the command stays `ng serve <project>`. ## Other serve options you meet in the same place - `headers` adds custom response headers, handy for testing a Content Security Policy locally. - `servePath` sets the path the app is served under; if it is not set, the dev server derives it from the build's `baseHref`. - `liveReload` and `hmr` control how changes reach the browser; those belong with the dev-server build pipeline rather than networking. ## The dev server is not a production server Whatever `host` you bind, `ng serve` is a development tool: it compiles on demand, watches files and injects live-reload code. The default serve target has `development` and `production` configurations, with `development` as the `defaultConfiguration`, and `ng serve --configuration production` only swaps the build target it serves; it is still the dev server. Exposing it on `0.0.0.0` for a demo is fine for a few minutes on a trusted network, never as a way to host the app. Production traffic goes to the output of `ng build`, served by a web server or, for server builds, by the generated Node server. ## Common mistakes - Expecting `http://<ip>:4200` to work while the server still listens on `localhost`. - Setting `allowedHosts: true` permanently in a shared `angular.json`. - Committing private keys referenced by `sslKey` into the repository.

  • What happens if you pass `--ssl` without a key and certificate?
    The dev server still serves HTTPS, using a self-signed certificate it generates at start-up. Browsers flag it as untrusted, so you accept a warning once per origin. To avoid the warning, create a certificate from a locally trusted development authority and pass it with `--ssl-key` and `--ssl-cert`.
  • Why not simply set `allowedHosts` to `true` for convenience?
    The host check limits which host names the dev server answers, and `true` switches it off for every name. The builder's own schema calls that not recommended and a security risk. List the specific names you use instead, such as a tunnel host or a local network name.

saying these in an interview costs you the question

  • ng serve on localhost is reachable from any device on the Wi-Fi.
  • ssl requires you to supply a certificate or it fails to start.
  • allowedHosts true is the safe default for team setups.
  • The dev server's port is fixed at 4200 by the builder.