Lixian.online: a proxy that hands you installer files instead of store pages

Four ecosystems, one paste-and-get URL form

Lixian.online is described as a one-stop tool to grab installer packages for VSCode extensions, Chrome and Edge add-ons, Docker images and Microsoft Store apps, with the promise of downloading once and installing anywhere, even offline. There is a live demo at lixian.online and a Chinese version of the documentation in the repository.

The feature table is the clearest description of what it does, and it is organised by what you paste in and what you get out. For a VSCode extension you paste a Marketplace URL and get a .vsix direct link. For a Chrome extension you paste a name, an extension ID or a Web Store URL and get a .crx and optionally a .zip. For a Microsoft Edge add-on you paste a name, a CRX ID, a ProductId or an Edge Add-ons URL and get the same .crx and .zip. For a Docker image you paste something like nginx:latest, library/nginx or a Docker Hub URL and get a docker load compatible .tar. For a Microsoft Store app you paste a Store URL, a ProductId, a PackageFamilyName or a CategoryId and get a .msix download link.

The variety of accepted identifiers is the practical part. A user who has a name and a user who has a ProductId are different people, and a tool that only accepts URLs forces everyone to go and look up a URL first. Accepting all the forms means you can paste whatever you have.

The output formats are equally deliberate. A .vsix is what the VSCode command line installs from. A .crx is what Chrome and Edge load as an unpacked or packaged extension. A .tar is what docker load consumes. And a .msix is the Microsoft Store package format. In each case the output is the artefact an installer expects, not a store page.

Running it locally is four pnpm commands

The project is a Next.js application with TypeScript, and running it from a checkout is short:

pnpm install
pnpm dev          # http://localhost:3000
pnpm build        # production build
pnpm start        # production server (default port 12723)

Note the two different ports. Development runs on port 3000, which is the Next.js default, while the production server runs on 12723, a port chosen to avoid colliding with a development server on the same machine. The package.json confirms it: dev runs next dev, build runs next build, and start runs PORT=12723 next start.

There are other scripts for the rest of the workflow. Linting is eslint, and the end to end tests are Playwright, with three variants: the plain test run, a headed variant for watching the tests in a real browser, and a UI variant. The dev script also runs Node with the inspect flag enabled, so a debugger can attach to the dev server, and there is a separate dev:e2e script that starts the app on 127.0.0.1 port 3100, which is a detail that matters when a test runner and a dev server would otherwise fight over the same port.

The dependency list is a normal Next.js stack: React 19 and React DOM 19, Next 16, Tailwind 4 with the PostCSS plugin, Radix UI primitives for select, slot, tabs and toast, axios for the outbound calls, lucide-react for icons, and Vercel Analytics. The pnpm configuration restricts which packages may run build scripts, to sharp and unrs-resolver only, which is the sort of setting that has become standard in JavaScript projects after the supply chain incidents of the last few years.

The Docker path is a multi-stage build with a non-root user

The repository ships a multi-stage Dockerfile and a docker-compose.yaml, and the compose file is where the production shape is visible:

    ports:
      - "12723:12723"
    environment:
      NODE_ENV: production
      PORT: "12723"
      HOSTNAME: 0.0.0.0

The compose service is named app, builds from the local Dockerfile context, runs as a container named lixian-online with a restart policy of unless-stopped, and maps the port one to one. The healthcheck is a plain node one-liner that fetches the root URL and exits zero when the response is ok, with a 30 second interval, a 5 second timeout, three retries and a 20 second start period. The HOSTNAME value of 0.0.0.0 is what makes the container reachable from outside, and it is set explicitly rather than left to the default.

The three compose commands are the standard ones:

docker compose up -d        # build the image and start in the background
docker compose logs -f      # follow logs
docker compose down         # stop and remove the container

Afterwards you open http://localhost:12723, and to change the host port you edit the ports mapping in docker-compose.yaml, with the README giving the example of 8080:12723.

The Dockerfile itself is a careful multi-stage build on node:22-alpine, with corepack enabled for pnpm, a deps stage that installs with a frozen lockfile and a pnpm store cache mount, a builder stage that copies the whole context and runs the production build, and a runner stage that copies only the standalone output, the static assets and the public directory. The runner creates a non-root user nextjs with uid 1001, switches to it, and starts node server.js. The base image is parameterised through a build argument, so the node version can be changed without editing the file.

The network path is the actual constraint

The self-hosting tips section contains the most important advice in the README, and it is about deployment rather than software.

The instruction is to pick a server with a clean route to the upstreams. This project proxies requests to Docker Hub, the Chrome Web Store, Edge Add-ons, the VSCode Marketplace, and Microsoft Store endpoints, and the network path from your server to these services needs to be fast and stable for downloads to work. From mainland China the route is often slow or unstable, so a VPS elsewhere, in Singapore, Japan, the US or Europe, is strongly recommended.

The failure mode the warning describes is specific and worth repeating: otherwise the page will load but downloads may hang or time out. The user interface is served from your own server and is therefore always fast, which makes the page look healthy, and the actual download is the part that is slow. That is a genuinely confusing symptom, and the README is warning about it in advance.

This tells you what kind of tool this is. It is not a mirror or a cache of the stores. It is a resolver plus a proxy, and every byte you download crosses the network path from the server to the upstream store, twice in effect, because the request goes to the server and the server then goes to the store. That is why the geography of the server matters so much.

One upstream is named explicitly in the acknowledgements. Microsoft Store package resolution relies on the public service provided by store.rg-adguard.net, so for Store apps the resolution is not done against Microsoft directly. That is worth knowing if you are relying on the service for a specific package, since it means a third party is in the path for that category.

Documentation and agent guidance live in the repository

Three documents are pointed at, and one of them is unusual for a project of this size.

There is docs/spec.md, described as the full behavior spec, and docs/api.http, which holds REST Client examples for local testing. The second one is a nice touch for a service with a REST surface, because the examples are executable rather than prose.

The third is CLAUDE.md, described as guidance for coding agents. For a project whose repository includes a file aimed at language model assistants, that is a signal about how the maintainer expects work to be done on the codebase, and it is increasingly common in active JavaScript projects.

The rest of the repository layout matches what you would expect. There is a src/ directory for the application, public/ for static assets, docs/ for the documents above, tests/ for the Playwright suites, and a playwright.config.ts at the root alongside next.config.js, tsconfig.json, postcss.config.mjs and eslint.config.mjs. There is also a CHANGELOG.md, a .release-please-manifest.json and a release-please-config.json, which show the releases are cut by release-please from conventional commits rather than by hand.

The release history is consistent with that. Tags run lixian-online-v0.5.5 from 2026-07-03, lixian-online-v0.5.4 from 2026-05-16 and lixian-online-v0.5.3 from 2026-04-22, and the last push to the main branch was on 2026-07-27. The package version in the manifest is 0.5.5 and the package is marked private, so the npm name is reserved rather than published.

A different approach from downloading on the machine itself

The alternative to this project is to do the download locally, and the difference in approach is about who pays the network cost.

Downloading directly on your own machine means the bytes travel from the store to you, once, over whatever route your network has. There is no proxy, no extra hop, and the region problem does not exist, because you are already where the store is fastest for you. The cost is that each package type has its own tooling: a browser extension has to be pulled from the Web Store by ID, a Docker image has to be saved with docker save, a VSCode extension can be fetched with a direct marketplace URL, and a Store package needs the package link.

The service inverts that. The download happens from the server, along a route the operator chose, and the result arrives at you as a file. That is what makes it work for a network that cannot reach the stores comfortably, and it is also what makes it slower and less private for a network that can. Every request goes through a third party host, and every byte you download is fetched twice, once by the server and once by you.

There is a third option, a genuine local mirror, where you sync the packages you need to storage you control and install from there. That gives you the offline property the README advertises, and it is the right answer for a fleet of machines or an air gapped environment. The service is not that: it resolves and proxies on demand, so the offline benefit it claims comes from the downloaded artefact being usable afterwards, not from the service being able to serve you later.

Editorial conclusion

Adopt Lixian.online if you need to fetch installer packages on a network that cannot comfortably reach the upstream stores directly, and you are willing to run the service yourself on a host with a clean route to them. Do not adopt it if you can reach the stores fine, since it adds a proxy in front of a download for no benefit, and do not treat it as an offline mirror, because the packages are fetched live from the upstreams rather than stored. Before you deploy it, read the self-hosting tip in the README and pick a server in a region with a fast path to Docker Hub, the Chrome Web Store, Edge Add-ons, the VSCode Marketplace and the Microsoft Store endpoints, since the page will load even when the downloads hang.

Frequently asked questions

Official sources

1. Issues
2. LiaoGuoYin/lixian.online on GitHub
3. Project website
4. README
5. Releases