What this site does not answer

Where does the boundary run?

The subject is the process that npm run dev, vite or vite dev starts: from the script that launches it, to the socket on 5173, to the requests it answers and the WebSocket it keeps open for HMR. Anything that only exists after the dev server has stopped, or before Vite has read its config, is outside. The test for every question is the same: does it change what localhost:5173 does?

• In: the port, the bind address, the host check, proxy and CORS, startup and pre-bundling, HMR, every server.* option.
• Out: what vite build writes, how .env values reach application code, how to write a plugin, how a framework configures Vite, and any port other than 5173 unless it is compared with 5173.

vite build opens no port, so nothing here applies to it

vite build runs the same config but never starts the dev server. Reproduced on 1 October 2026 with Vite 8.3.1: the build prints no Local line, writes its files and exits. The output goes to build.outDir, which defaults to dist, and the default mode switches from development (serve) to production (build). The server.* options on this site do not configure that run — the build has its own build.* section in the docs. The one place a build meets this site is /preview-port/, because vite preview serves the dist folder on 4173.

$ npx vite build
vite v8.3.1 building client environment for production...
✓ 4 modules transformed.
dist/index.html                0.10 kB │ gzip: 0.11 kB
dist/assets/index-BIThVYFU.js  0.72 kB │ gzip: 0.42 kB
✓ built in 21ms

# no "Local:" line — nothing is listening, 5173 stays closed

Environment variables are covered only where they would move the port

Modes, .env file order and import.meta.env are a subject of their own and stay with the Vite documentation. One rule touches 5173 directly: .env files are not loaded into process.env while vite.config runs. The docs say so in "Using Environment Variables in Config", and the reproduction agrees — a .env with VITE_PORT=4800 still starts the dev server on 5173. To let a .env value set server.port, the config has to call loadEnv itself. For the PORT variable specifically, see /config-vs-cli/.

• Only variables starting with envPrefix — default VITE_ — reach client code. In the same reproduction the bundle contained 123 from VITE_KEY and nothing from SECRET.
• .env files are read when Vite starts. Editing one while 5173 is running changes nothing until the dev server is restarted.

# .env: VITE_KEY=123  SECRET=abc  VITE_PORT=4800
$ npx vite

  VITE v8.3.1  ready in 64 ms

  ➜  Local:   http://localhost:5173/
  ➜  Network: use --host to expose

# VITE_PORT is exposed to the app, not read by the config

Plugins can change what 5173 answers — the pages here check Vite without them

A plugin reaches into the dev server through the configureServer hook. The plugin API docs state that the hook runs before Vite installs its internal middlewares, so a plugin middleware sees a request on 5173 before Vite does. The same docs note that configureServer is not called during the production build. That is why a page here can be right for Vite and still not match a project with plugins: if 5173 behaves differently from what a page describes, start the dev server once with the plugins removed. Writing plugins is not covered.

Framework wrappers set their own defaults, and those are not verified here

Nuxt, SvelteKit, Astro and Remix run Vite underneath but ship their own config layer and their own port defaults. A plugin config hook outranks both vite.config.js and the CLI flag — /config-vs-cli/ shows the order — so a wrapper can change port, host or proxy without the project config saying so. Those defaults belong to each framework and cannot be checked against vite.dev, so this site makes no claims about them.

With server.middlewareMode, the port belongs to your server

server.middlewareMode defaults to false. When it is true, Vite hands its middlewares to a server you create and does not decide the port. The SSR guide shows this with an Express app that ends in app.listen(5173) — the same number, but a different owner. Pages here describe Vite listening on 5173 itself; for an embedded setup the SSR guide is the reference.

Other ports appear only as a comparison with 5173

Port 4173 has its own page because vite preview is the closest neighbour of the dev server and the source of bugs that do not reproduce on 5173. Ports like 3000 or 8080 appear in the table on the home page, always answering one question: is the server on this port the Vite dev server or not? There is no port directory here.

• Every server option that changes what localhost:5173 doesEverything the dev server on localhost:5173 does is configured under the server key in vite.config.js — twenty options, of which only host, port, strictPort, open and cors have a CLI flag; the rest exist in the config file only.
• How every claim on this site is verifiedEvery page here is checked against one named Vite release — 8.3.0, published 2026-09-10 — in three places in a fixed order: the documentation, the source at that release tag, and a local reproduction, and the date of that check is printed at the foot of the page.
• vite.config.js or a CLI flag — which one wins on port 5173A CLI flag such as --port overrides the same option in vite.config.js, but a plugin that sets the option in its config hook overrides both, because Vite merges plugin results after the command line.
• Port 4173: vite preview, not the dev servervite preview serves the finished build from dist/ on port 4173, while the dev server on 5173 compiles your source on the fly — they are two different servers with two different ports.
• localhost:5173 — the port itselfWhat the address means, common dev ports, and the autocomplete fix.