# winstall for Windows: Browse winget Apps and Generate Scripts

> winstall is a web interface for selecting Windows Package Manager apps and producing batch or PowerShell commands. It suits Windows users who want a visual catalog, while direct winget use remains the clearer option for controlled administration.

**SplashtopInc/winstall** — A web app for browsing and installing Windows Package Manager apps. 

- Repository: https://github.com/SplashtopInc/winstall
- Website: https://winstall.app
- Stars: 1,376 · Forks: 71
- Language: JavaScript
- License: GPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/splashtopinc-winstall

## Why winstall Exists Above the winget Command Line

winstall addresses package discovery and script assembly for people who want Windows Package Manager applications without remembering package identifiers or composing installation commands by hand. Its intended users are Windows 10 and Windows 11 users selecting one or more applications through a browser. The application presents searchable app data, an all-apps view, and a selection interface that produces a command for Windows Package Manager, known as winget.

That division of responsibility matters. winstall does not replace winget or own the installation process. It acts as the catalog and script-building layer, while winget performs the package operations on the target Windows machine. This makes winstall most useful for an individual assembling a set of desktop applications. It is less convincing as the control plane for an organization that already manages package versions, deployment groups, silent policies, and approved manifests elsewhere.

The project also allows a downloaded `.bat` or `.ps1` file rather than requiring users to paste the displayed command. That convenience introduces a separate review point: the README says a browser security warning may appear for the downloaded script. It instructs users to ignore the warning and calls the batch file completely secure, but the README does not provide a reproducible audit procedure for evaluating generated scripts. Engineers should read the package identifiers and commands before execution rather than treating a download notification as permission to run them.

## How winstall Converts App Selections into Windows Commands

The documented flow begins with a search on the homepage or a visit to the all-apps page. A user selects packages, chooses `Generate Script`, and receives a command that can be pasted into a Windows command-line application. The README says winget then installs the selected applications one by one. Enabling `Show Powershell scirpt`, spelled that way in the README, changes the generated output to PowerShell.

The catalog is described as coming from an API that checks Microsoft's `winget-pkgs` repository. According to the README, weekday updates occur every 15 minutes and weekend updates occur every three hours. Those intervals describe the documented API refresh schedule. They do not guarantee that a selected manifest, installer binary, or package version is newly published at the moment the script runs.

The repository layout indicates that the current project is broader than a static search page. It contains Next.js application files under `pages/`, interface code under `components/`, service code under `service/`, shared context and hooks, tests, service-worker files, and Docker configuration. `package.json` identifies version `2.5.1` and declares React, Next.js, MongoDB, Redis, NextAuth, AWS S3, drag-and-drop, and service-worker dependencies. These files show a production-oriented web application, but the README does not explain every service boundary or document a complete production request flow.

One historical README statement deserves particular care. It says the API will be made open source in the future, while the repository now has a `service/` directory. The directory structure does not establish which API code, if any, is deployed by `docker-compose.yml`, or how it relates to the historical API. An adopter should confirm the deployed API's source, availability, and update behavior rather than infer all of them from that statement.

## First Use: Search, Select, Generate, and Inspect

The simplest first use is the hosted interface at `https://winstall.app`. The README says users can search on the homepage, select applications, and press the `Generate Script` button at the bottom of the screen. After reviewing the output, the user can copy it into a Windows command-line application. No local installation is required for that hosted workflow.

For a local development checkout, `package.json` requires Node.js `>=20.9.0` and the repository includes `package-lock.json`. The following documented package scripts install dependencies and start the development server:

```bash
npm ci
npm run dev
```

`npm ci` installs the dependency tree recorded in `package-lock.json`. `npm run dev` first removes generated service-worker files through `clean:sw`, then starts Next.js with Turbopack. The README does not state the development URL, so the terminal output should be used to find the address exposed by Next.js.

A local development run is not automatically self-contained. `.env.example` lists authentication variables, `WINSTALL_API_BASE`, `WINSTALL_ICON_BASE`, and `WINSTALL_BUILDER_BASE`. It also contains optional Redis and S3 settings. The repository does not include a populated `.env` file, so the service may start with incomplete capabilities or fail where an external endpoint is required.

For the first package installation, use the browser workflow before moving to downloaded scripts. Search for an application, select it, press `Generate Script`, and inspect the returned package identifiers and winget operations before pasting the command into Windows. Keeping the command visible makes it easier to compare the generated output with the package selected in the interface. The README does not publish a concrete output example, so it does not establish the exact formatting produced for a particular selection.

## Docker Compose Adds MongoDB and an External Network

The repository includes a multi-stage `Dockerfile` based on `node:22-slim`. It runs `npm ci`, copies the application into a build stage, and executes `npm run build` with `STANDALONE_BUILD=true`. The runtime image copies the Next.js standalone output, static assets, and public files, exposes port `3000`, and starts `node server.js`.

`docker-compose.yml` defines the application and a `mongo:8` service. The application receives `MONGODB_URI`, `USE_HOST_INTERNAL`, and production network settings, while MongoDB data is retained in the named `mongo2-data` volume. Its health check requests `/api/health` on port `3000`; MongoDB is checked with a `ping` command. Redis appears in `.env.example` and `package.json`, but it is not a service in `docker-compose.yml`. The example says Redis is optional and that caching falls back to memory when Redis is not configured.

A deployment constraint appears in the network definition. The `backend` network is declared as `external: true` with the default name `winstall-network`. Compose therefore expects that network to exist outside the generated project stack. The repository does not include a command for creating it, so the deployment owner must account for that prerequisite separately.

The Compose file loads `.env` through `env_file`, but `.env.example` is not a ready-to-run deployment configuration. It includes placeholder authentication credentials and references API, icon, and builder services. Copying it without replacing placeholders or confirming which endpoints are required would create a misleading sense of readiness. The README focuses on the hosted user experience and does not document a complete production Docker setup.

## Maintenance, Licensing, and Service Boundaries

The repository is not archived, and the last push was on 2026-10-14. That date shows recent repository activity, but it does not establish a release cadence or a tested compatibility range for Windows Package Manager. The repository has no GitHub releases, so there is no release history to use as an upgrade baseline. `package.json` records version `2.5.1`, but that field is project metadata rather than proof of a published GitHub release.

Upgrade work spans several dependency groups. The application declares Next.js 16 and React 19, while `package-lock.json` records transitive package versions. MongoDB holds application data and must remain available during a deployment change. Redis and S3 are optional according to `.env.example`, but enabling them adds configuration and service-management duties. A self-hosted operator must also decide how the API, icon service, and builder endpoints are supplied through the listed base URL variables.

The project uses the `GPL-3.0` license. That identifier matters when distributing a modified version or incorporating covered code into another distribution, but this review does not provide legal advice. Reviewers still need to read the repository's `LICENSE` file and assess the obligations that apply to their distribution model.

Generated commands create an additional review boundary. The README says the API checks Microsoft's official `winget-pkgs` repository, but catalog presence does not replace organizational approval. Review package identifiers, sources, installer behavior, and version policy before execution. The README does not document whether winstall exposes installer hashes, signatures, publisher verification status, or package provenance details inside its interface.

## Direct winget Use Compared with winstall's Catalog

The direct alternative is to use Windows Package Manager itself. winget is the installer engine documented for Windows 10 and Windows 11. A direct workflow starts with known package identifiers and explicit winget commands, while winstall adds browser search, multi-selection, and script generation around that engine. The README does not present a direct winget installation example, so it does not establish the exact command syntax used for individual packages.

Direct winget use is the better fit when automation already knows package identifiers and must preserve an explicit command policy. It removes the catalog and script-generation layer. winstall is the better fit when a user does not know the identifiers, wants to browse available applications visually, or wants a batch or PowerShell script assembled from several selections.

There is also a hosting choice within winstall. The hosted web app is the quickest route for browsing and generating a command. Running the repository locally requires Node.js configuration or a Docker deployment with MongoDB and external services. Self-hosting puts the web layer under the operator's control, but the README does not establish that a local winstall instance owns or replaces the upstream package API. It should therefore be treated as a deployable catalog client, not automatically as an offline package-management system.

## Conclusion

Adopt winstall when a Windows user benefits from visual package discovery and shareable installation commands. Do not adopt it as a replacement for controlled winget automation, deployment management, or package approval policy. Verify first that Windows has winget, inspect every generated package identifier, and confirm that the API, MongoDB, network, and optional service dependencies fit the intended deployment.

## FAQ

### What operating systems and package manager does winstall support?

winstall targets Windows Package Manager applications, known as winget, on Windows 10 and Windows 11. The README describes winget as being available by default on those Windows versions.

### Does winstall install applications itself?

No. winstall generates a command or downloadable `.bat` or `.ps1` file, while winget performs the installation on the target Windows machine.

### Can winstall generate PowerShell instead of a batch command?

Yes. The interface provides a `Show Powershell scirpt` option that changes the generated output to PowerShell.

### Can I run winstall locally with Docker Compose?

The repository provides a `Dockerfile` and `docker-compose.yml`. The Compose setup also expects MongoDB and an existing external `winstall-network`, although the repository does not provide a network-creation command.

### Where does winstall get its application catalog?

The README says an API checks Microsoft's official `winget-pkgs` repository. It documents weekday refreshes every 15 minutes and weekend refreshes every three hours.

## Sources

- [Issues](https://github.com/SplashtopInc/winstall/issues)
- [License: GPL-3.0](https://github.com/SplashtopInc/winstall/blob/master/LICENSE)
- [Project website](https://winstall.app)
- [README](https://github.com/SplashtopInc/winstall/blob/master/README.md)
- [SplashtopInc/winstall on GitHub](https://github.com/SplashtopInc/winstall)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/splashtopinc-winstall