anywhere: a static file server that turns the current directory into a web root

One command and a browser opens

anywhere is a static file server you start with a single command, and the promise in the project description is that it turns your current directory into the root of a static file server, wherever you happen to be.

The install is a global npm install:

npm install anywhere -g

And the execution is the shortest possible form:

$ anywhere

The default is port 8000 with the current folder as root, and the documentation says the default browser is opened automatically once the command runs. The visit URL is http://localhost:8000.

The tool is a JavaScript project distributed through npm, with the package name anywhere, version 1.7.0, and a bin entry pointing at ./bin/anywhere. The author is Jackson Tian, and the licence field in the package metadata reads MIT, with an MIT-License file in the repository root, though the repository-level metadata is listed as a custom licence that GitHub cannot classify, so the MIT-License file is the one to read.

There are no published GitHub releases, so the npm version is the version that matters. The last push to the repository was on 2026-10-13, and the repository is not archived, so the project is still being worked on even though there is no changelog visible in the top level listing.

The build and test setup is minimal and modern. The test script runs node --test test/*.test.js using the built-in Node test runner rather than a framework, with a separate test:cov script that wraps it in c8 for coverage, and lint scripts that run eslint over bin/anywhere with and without --fix.

The flags, and what the shorthand ones hide

The command line is small and each flag does one thing.

$ anywhere
// or with port
$ anywhere -p 8000
// or start it but silent(don't open browser)
$ anywhere -s
// or with hostname
$ anywhere -h localhost -p 8888
// or with folder
$ anywhere -d ~/git/anywhere
// or enable html5 history
$ anywhere -f /index.html

There is also a positional form, where anywhere 8888 means port 8888, according to the help output.

The full help text lists the shorthands alongside the long forms:

$ anywhere --help
Usage:
  anywhere --help // print help information
  anywhere // 8000 as default port, current folder as root
  anywhere 8888 // 8888 as port
  anywhere -p 8989 // 8989 as port
  anywhere -s // don't open browser
  anywhere -h localhost // localhost as hostname
  anywhere -d /home // /home as root
  anywhere -f /index.html  // Enable html5 history,the index is /index.html
  anywhere --proxy http://localhost:7000/api // Support shorthand URL, webpack.config.js or customize config file

Two of these deserve comment because they change what the tool is for. The -f flag enables HTML5 history mode with a given index file, which is what you need when serving a single page application: without it, a browser that requests /some/route directly gets a 404 instead of the app shell. And -s suppresses the automatic browser launch, which is the flag you want in a script or a container.

The -h flag setting a hostname is a security-relevant default, because it determines what the server binds to and what host header it expects. Leaving it unset means the default behaviour, and the documentation example sets it explicitly to localhost.

The -d flag serving a different folder is the one to be careful with. Pointing it at a home directory serves everything in that directory, which is not something you want to do on a shared network.

Proxying API calls with the same middleware webpack uses

The proxy feature is the part that turns anywhere from a file server into a front-end development companion, and it is built on http-proxy-middleware.

The shorthand form takes a single URL:

anywhere --proxy http://localhost:7000/api
                 \___________________/\___/
                              |         |
                           target    context

The target is the server to forward to, and the context is the path prefix under which the requests are matched. The documentation links to the http-proxy-middleware shorthand configuration for the details of the matching rules.

The second form is to reuse a webpack dev server configuration, so that the proxy settings you already have in webpack.config.js apply to anywhere as well:

// webpack.config.js
module.exports = {
  devServer: {
    proxy: {
      '/api': {
        target: 'http://localhost:7000',
        changeOrigin: true
      }
    }
  }
}

And the third is a dedicated proxy config file:

// proxy.config.js
module.exports = {
  '/api': {
    target: 'http://localhost:7000',
    changeOrigin: true
  }
}

The difference between the second and third is one of structure rather than behaviour. The webpack form nests the proxy map under devServer because that is where webpack expects it, and the standalone form is the bare map. The changeOrigin setting is worth understanding, since it rewrites the Host header on the forwarded request so that the upstream server sees the host you asked for rather than the proxy's own address, which matters for virtual hosting and for frameworks that build absolute URLs from the request.

The documentation links to the http-proxy-middleware context matching documentation for the details of the matching rules.

The dependency set, and where the design came from

The dependency list explains the design in a way a feature list would not.

The server itself is connect, the classic Connect middleware stack, with serve-static for the file serving, serve-index for directory listings, mime-types for content type detection, and connect-history-api-fallback for the HTML5 history support behind the -f flag. On top of that sits http-proxy-middleware for the proxy, minimist for the argument parsing, and debug for the logging. The test tooling is the built-in node test runner with c8 for coverage and eslint for linting.

That is a deliberate choice to build on the same middleware ecosystem that Express and the rest of the Node HTTP world use, rather than on Node's raw http module. The consequence is that the behaviour is the behaviour of well-trodden middleware, and the composition is legible if you know Connect.

The repository layout is consistent with a small CLI project: a bin directory with the executable, a lib directory for the implementation, a keys directory, a test directory, an eslint.config.js at the root, and the package-lock.json for reproducible installs. The package files field lists only bin and keys, so the published npm tarball is the executable and whatever it needs at runtime, not the tests or the eslint configuration.

The keys directory is a loose end in the documentation. It is included in the published package alongside the bin directory, but the README covers only the CLI, the proxy configuration and the licence, and says nothing about what the keys are for. If that matters to you, the source is where you will find the answer.

The practical use that motivates all of this is serving to another device rather than to yourself. Because the tool takes a hostname and a port, the same command that opens a browser on your laptop also serves the directory to a phone on the same network, which is how you check a static build on a real screen rather than in a desktop emulator. The -s flag exists for exactly that case, since you do not want a browser window opening every time the server restarts in a loop.

The overall philosophy is stated in the README in both languages, that you can turn your current directory into a static file server at any time, and the project is deliberately lightweight, with the whole point being that it starts immediately with no configuration file.

Editorial conclusion

anywhere fits someone who needs to serve a directory of files to another machine, or to a phone on the same network, without configuring anything, and it fits front-end developers who want a proxy to a local API while iterating on a static build. It is a poor fit for production use, since it opens a browser and binds a port with no authentication or TLS, and it is a poor fit if you need directory listings disabled or a hardened server, because it will serve whatever is in the folder. Before running it, check whether your firewall exposes the port, and if the directory contains anything private, serve a copy rather than the original.

Frequently asked questions

Official sources

1. Issues
2. JacksonTian/anywhere on GitHub
3. README