# PortApps: Windows applications that live in a folder you can carry

> PortApps is a collection of portable Windows applications, where each application is wrapped by a small Go executable that redirects the application's data into a folder of its own, so the whole thing can be moved to a USB stick and run from there. It suits people who need a tool to leave no trace on a machine, and it depends on the upstream applications permitting redistribution.

**portapps/portapps** — 🛰 Collection of portable apps for Windows

- Repository: https://github.com/portapps/portapps
- Website: https://portapps.io
- Stars: 1,233 · Forks: 81
- Language: Go
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/portapps-portapps

## A wrapper, not the applications themselves

PortApps is a collection of portable apps for Windows, and you can download your favourite application as a portable setup or as a 7z archive.

The important thing to understand is what the project actually is. It is not a set of applications and it does not port anything. Each portable app is executed through a wrapper, named with the pattern appname and the portable suffix and ending in an executable, and that wrapper is written in Golang with the purpose of making the application portable.

So the structure of a portapps package is the original application, unmodified, plus a small Go program that launches it with the environment redirected. The wrapper is the whole contribution.

The consequence is stated in the README, that this allows you, for example, to use your favourite application on a USB stick. The application believes it is writing to its usual locations, and the wrapper makes those locations point inside the portable folder, so the folder is the entire footprint.

That is the trick, and it is the same trick that portable versions of popular applications have used for years. What PortApps adds is a collection, a consistent wrapper across many applications, and a website that makes them easy to find.

The licence is MIT, with the rocket icon credited to Squid Ink, and the releases are v3.19.0 from 2026-08-30, v3.18.0 from April 2026 and v3.17.0 from September 2025, with the last push to the repository on 2026-10-09.

## What the Go wrapper is actually doing

The repository layout is the wrapper, and it is small enough to describe in a few files.

There is a main file for the program, a config file for the configuration handling, a dialog file, a logger file and a utility file, plus a pkg directory for the packages the wrapper is built from and a res directory for the resources, which is where the icon and the other assets live. There is also a build directory with the build configuration.

The module is published under a versioned path, which is the Go convention for a major version, and it declares a recent language version.

```toml
module github.com/portapps/portapps/v3

go 1.26.0
```

The dependency list is short and it describes the job better than the prose does. The Windows OLE and COM binding library is there, and that is the interesting one, because on Windows a portable application usually has to redirect the things the operating system exposes through COM and the registry, such as the shell known folders, and that is what an OLE binding is for.

The rest is ordinary infrastructure. A structured logging library, a YAML parser for the configuration file, a rotator for writing logs so they do not grow without bound, a map structure decoder for turning the configuration into Go values, the test assertion library, and the system package for low level operating system calls.

None of these are heavy, which is what you want in a program whose only job is to start another program and adjust where it writes.

## Configuration, and the site as the front door

The README is short and it points outward, and the outward links are the actual documentation.

The site at portapps.io has a collection page listing the applications, a configuration page, a frequently asked questions page, a page for reporting an issue, a page for requesting an app, and a contribute page. The configuration page is the one to read before you run anything, because the behaviour of the wrapper is configured rather than hardcoded, and the README links it as a first class destination rather than burying it.

The contribution process is described in the same terms. The most basic way to support the project is to star it or to raise issues, and if you want to open a pull request you should read the contributing guidelines. Funding is through GitHub Sponsors and PayPal, with the message that it keeps the journey continuing indefinitely.

The request an app page is worth noticing for a structural reason. The collection is not limited to what the project can build itself, it is extended on request, which means the set of applications in it is a function of what users ask for. For a project whose value is coverage, that is the right mechanism, and it also means the quality of the collection depends on a queue of requests being worked through by contributors.

The issue reporting page exists separately from the GitHub issue tracker, which is a small signal that the repository is not the whole project, and that the artefacts people actually run are distributed from somewhere else.

## What portability means on Windows, and where the limits are

The value of the approach is that the application is not modified, which is what makes it safe to redistribute and what keeps it working when the application updates. The cost is that the wrapper has to persuade a program that was not written for this that its data belongs somewhere else.

On Windows that means the registry, the shell known folders, and the COM interfaces the application uses to find them. Redirecting them is what the OLE dependency is for, and it is also where the fragility lives. An application that stores its data somewhere unusual, in a location the wrapper does not know about, will leave files behind on the machine it ran on, and nothing in the project can prevent that. A portable application that leaves a trace in the temporary directory or writes to an absolute path it computed itself is not portable in the sense the wrapper intends.

The second limit is the upstream application. PortApps distributes other people's software, and the permission to do so comes from each application, not from this project. A collection entry is only possible where the upstream author allows redistribution, which is why the list looks the way it does, and it is why a build of an application that changes its licence can disappear from the collection without the wrapper changing at all.

The third is the platform. This is a Windows project, and the wrapper is a Windows executable, so none of it applies on macOS or Linux, where portable application conventions are different anyway and where the usual approach is a flatpak or a container.

## The alternative, and how to choose

There are two other ways to get the same result, and the choice depends on what you are actually worried about.

The first is the application that ships its own portable edition. Several well known Windows applications already offer one, and where that exists it is a better answer than a wrapper, because the vendor has already solved the redirect problem properly and will keep solving it as the application changes. The wrapper only wins on coverage, in the cases where no official portable build exists.

The second is a sandbox or a virtual machine, where the isolation happens at a different layer entirely. A virtual machine gives you stronger isolation than a redirected folder, at a cost in memory and startup time, and it needs a hypervisor on the machine. A sandbox is somewhere in between. The advantage of the portable folder over both is that it is the least intrusive of the three: no hypervisor, no extra copy of the operating system, and the application runs at full speed because it is a normal program with a few paths pointed elsewhere.

So the decision comes down to what the threat is. If the concern is leaving settings and history on a shared machine, the portable folder is enough. If the concern is a hostile application or a strict compliance rule about what may run at all, none of these three is enough and the answer is a virtual machine.

For the ordinary case, a colleague's laptop, a school machine, a USB stick you carry between two computers, the wrapper is the lightest thing that works, and PortApps is a collection of them with a consistent shape.

## The state of the project, and where it fits

A few practical notes to close on.

The project is under active maintenance, with releases in April and August 2026 and a push to the repository on 2026-10-09, so the wrapper is being kept working against current versions of the applications it wraps. That maintenance is the whole commitment of the project, since a wrapper that is not updated against a changed application is a broken portable copy.

The code is a single Go module with a small set of files at the root, which means the wrapper is a program you could read end to end in an afternoon. That matters if you are extending it, and it is also why the project can accept contributions for a new application without a large review burden.

The documentation is entirely on the site rather than in the repository, which is a deliberate arrangement for a project whose users arrive at a download page rather than at a source tree. The trade is that the configuration semantics, the frequently asked questions and the contribution rules live in one place, and the code in another.

For an adopter, the path is short. Pick an application from the collection, download the portable setup or the 7z archive, put it on the stick, and run the wrapper. The one thing to check first is the configuration documentation, because that is where the behaviour of the redirect is described, and it is the part that determines whether the application really does leave nothing behind.

## Conclusion

Adopt PortApps if you routinely use a tool on machines you do not own, such as a lab machine or a borrowed laptop, and you want its settings and cache to stay in one folder you can take with you. Do not adopt it for a tool you can install normally, because the wrapper adds a layer between you and the application and buys nothing there. Before you redistribute a build, check the upstream application's own licence, since the wrapper is MIT but the application inside it is not, and read the configuration documentation, because the redirect behaviour is what makes the app portable.

## FAQ

### What is PortApps?

It is a collection of portable apps for Windows. You can download your favourite application as a portable setup or as a 7z archive, and each portable app is executed through a wrapper named with the app name and the portable suffix, written in Golang, whose purpose is to make the application portable so it can be used from a USB stick.

### How do I get a portable app from PortApps?

The collection is browsable at the project site, and each entry can be downloaded as a portable setup or as a 7z archive. The site also has pages for configuration, frequently asked questions, reporting an issue, requesting an app and contributing.

### What language is the PortApps wrapper written in and what does it depend on?

It is written in Golang, and the dependency list is short, including a Windows OLE and COM binding, a structured logging library, a YAML parser, a log rotator, a map structure decoder, the test assertion library and the system package.

### Can I use a PortApps build on macOS or Linux?

No. The project is a collection of portable apps for Windows, and the wrapper is a Windows executable that redirects the registry and shell locations the applications use, so the approach is specific to that platform. The MIT licence covers the wrapper, and redistribution of the wrapped applications depends on their own licences.

## Sources

- [License: MIT](https://github.com/portapps/portapps/blob/master/LICENSE)
- [portapps/portapps on GitHub](https://github.com/portapps/portapps)
- [Project website](https://portapps.io)
- [README](https://github.com/portapps/portapps/blob/master/README.md)
- [Releases](https://github.com/portapps/portapps/releases)

---

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