# auto-py-to-exe: a PyInstaller front end for people who do not want to memorize flags

> auto-py-to-exe wraps PyInstaller in a browser-based form so you can pick a script, tick options and get a Windows executable. The trade-off is that you inherit PyInstaller's behaviour without learning the command line that controls it.

**brentvollebregt/auto-py-to-exe** — Converts .py to .exe using a simple graphical interface 

- Repository: https://github.com/brentvollebregt/auto-py-to-exe
- Stars: 4,990 · Forks: 816
- Language: JavaScript
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/brentvollebregt-auto-py-to-exe

## The gap auto-py-to-exe fills between a script and a double-clickable file

PyInstaller is the tool that actually bundles a Python program into a standalone executable. It is a command-line program with a long option list, and the README of auto-py-to-exe describes the project as "a .py to .exe converter using a simple graphical interface and PyInstaller in Python." The interface is the product. It does not replace the bundler; it collects the choices PyInstaller needs and then runs it for you.

The audience is narrow but real. Someone who has written a small script, wants to hand it to a colleague on Windows, and has no interest in learning what --onefile, --add-data or a spec file means can open a form instead. The README's own workflow is four steps: select the script location, select other options and add an icon or other files, click the big blue button at the bottom to convert, then find the converted files in /output when completed. There is no build system, no manifest, no CI integration described. That is the point.

It is a poor fit if you already have a working PyInstaller invocation. A command line is easier to diff, review and reproduce than a set of checkboxes, and auto-py-to-exe's JSON configuration export is explicitly a convenience for re-entering the same values, not a build artifact.

## How the interface, Eel and PyInstaller fit together

The package is JavaScript-heavy for a Python tool, and setup.py explains why: the install requirements are Eel, PyInstaller and requests. Eel is the piece that serves a local web UI and connects it to Python functions. So the window you see is a browser page, and the README notes that to have the interface displayed in the images you need Chrome, though if Chrome is not installed or --default-browser is passed, the default browser will be used.

That architecture has a visible consequence. The application is not a native window; it is a local server plus a browser view. The --no-ui flag exists precisely because of this: it does not try to open the UI in a browser and simply prints out the address where the application can be accessed. That is useful on a headless or remote machine, but it also confirms that the UI is a web app you reach over a local address.

Data flow is straightforward. You fill fields in the page, the Python side assembles the equivalent PyInstaller invocation, and the resulting files land in the output directory. The README says the converted files are found in /output when completed. Nothing in the repository suggests a separate build engine, so the fidelity of the result is the fidelity of PyInstaller, no more and no less.

## Installing auto-py-to-exe and converting a first script

The documented path is PyPI. The prerequisites section lists Python 3.6 to 3.14, and setup.py repeats python_requires=">=3.6". Install and launch with two commands:

```bash
pip install auto-py-to-exe
auto-py-to-exe
```

The README notes that if you have more than one version of Python installed, you can use `python -m auto_py_to_exe` instead of `auto-py-to-exe`. The same command is used after the GitHub install path, which the README gives as git clone, cd auto-py-to-exe and python setup.py install.

Once the UI is open, the flow mirrors the README's four steps. Point the Script Location field at your file; the outline will become blue if the file exists. Add an icon or other files if you need them, then click the big blue button at the bottom to convert. When it finishes, find your converted files in /output. If you want to skip the clicking on later runs, the application accepts arguments:

```bash
auto-py-to-exe --help
```

The README gives this as the way to get the usage. The positional filename pre-fills the Script Location field in the UI, and -o / --output-dir sets the default output directory, which the README says can still be changed in the UI. For a first build, that is enough to get an executable out the other side.

## The JSON configuration is a form state, not a build definition

The README is unusually candid about a limitation here. You can export the current UI state from the Configuration section within the settings tab and import it again to re-populate all fields. But the export action does not save the output directory automatically, because moving hosts could mean different directory structures. If you want the output directory in the JSON config, you must add the directory under nonPyinstallerOptions.outputDirectory, which the README says will need a new key created.

That single design decision tells you what the config is for. It is a way to avoid retyping the same values on one machine, not a portable build recipe. If your team shares a config file across machines with different layouts, the output path will not travel with it unless someone edits the JSON by hand. Treating this file as the source of truth for a release is a misuse the README does not encourage.

There is also no documented rollback. The README does not describe undoing a conversion or reverting a config import, and the repository's own examples are readme files under examples/ rather than automated tests of the output. Verification of a built executable is left to the person who built it.

## Where auto-py-to-exe stops being the right tool

The most concrete limitation is platform. The README's badge lists Windows, Linux and macOS, and setup.py's classifiers list Microsoft Windows and POSIX Linux. PyInstaller does not cross-compile: the executable you get is for the machine you built it on. So the common request to build a Windows .exe from macOS is not something this interface can solve, and the project does not claim otherwise. You build on Windows to ship to Windows.

Antivirus interference is acknowledged in the argument table. The -bdo / --build-directory-override option is described as useful "if you need to whitelist a folder to stop your antivirus from removing files." That is a real failure mode: a build can fail because a security product quarantines intermediate files, and the documented workaround is to redirect the build directory to somewhere you can whitelist.

Finally, the interface limits what you can express. Every option you cannot find in the form is an option you cannot set without leaving the tool. The README does not document a way to hand-edit the underlying PyInstaller command inside the UI, so complex builds with custom hooks or unusual data layouts will push you back to the command line. That is not a defect so much as the boundary of a front end.

## auto-py-to-exe against writing the PyInstaller command yourself

The real alternative is PyInstaller directly, which auto-py-to-exe already depends on (pyinstaller>=5.8.0 in setup.py and requirements.txt). The difference is not capability but interface and repeatability. With PyInstaller alone you write one command, put it in a script or a Makefile, and get the same result on every run. With auto-py-to-exe you get discovery: the form shows you options you did not know existed, which is genuinely useful the first time.

A second alternative is a packaging approach that does not produce a single executable at all, such as shipping a Python environment plus an entry point. That avoids the bundling step entirely, but it moves the problem to the user's machine, which is exactly what people reach for auto-py-to-exe to avoid.

The honest comparison is this: auto-py-to-exe is a learning and one-off tool, and PyInstaller is the automation tool underneath it. Once you know which flags you need, the interface adds a browser dependency and a manual step. The project's own --config flag is a partial bridge, letting you provide a configuration file (JSON) to pre-fill the UI, but it still opens a UI rather than running a headless build.

## Maintenance, licensing and what the repository tells you about cost

The project is MIT licensed, according to setup.py's license field and the LICENSE file at the repository root. That is permissive: you can use, modify and redistribute it, including in commercial settings, provided the licence terms are met. This is a description of the licence text, not legal advice, and anyone embedding it in a product should read the LICENSE file themselves.

The last push to the default branch was on 2026-09-11, and the most recent release listed is v2.50.1 from 2026-04-19. The repository is not archived. There is a CHANGELOG.md, a CONTRIBUTING.md and a tests/ directory at the top level, and the README links translations of the readme into a translations/ folder, so the project has an established release and contribution process.

Upgrade cost is tied to PyInstaller, not to this project. Because auto-py-to-exe calls PyInstaller rather than reimplementing it, a PyInstaller change can alter your output even if the interface looks identical. The README's platform badge and the Python 3.6 to 3.14 range are the two compatibility facts worth checking before you pin a version.

## Conclusion

Use auto-py-to-exe when you need one or two executables and would rather click through options than read PyInstaller's flag list, especially on Windows where the README's screenshots and examples are aimed. Skip it if you ship builds from CI, need reproducible command-line invocations, or target platforms where you cannot test the result. Before adopting it, check that your Python is between 3.6 and 3.14, that your target machine has the same OS family as your build machine, and that you are willing to fall back to the generated PyInstaller command when the interface does not expose what you need.

## FAQ

### How do I install auto-py-to-exe?

Install it from PyPI with pip install auto-py-to-exe, then run the auto-py-to-exe command. The README also documents installing from GitHub with git clone, cd auto-py-to-exe and python setup.py install.

### How do I use auto-py-to-exe to convert a script?

Open the UI, select your script location (the outline becomes blue if the file exists), choose any other options or files, and click the big blue button at the bottom to convert. The README says the converted files are found in /output when completed.

### How do I open auto-py-to-exe?

Run auto-py-to-exe in a terminal after installing it. The README notes that with more than one version of Python installed you can use python -m auto_py_to_exe instead, and that the UI opens in Chrome if available or your default browser otherwise.

### Can I run auto-py-to-exe on Windows?

Yes. The README lists Windows, Linux and macOS, and setup.py declares Microsoft Windows and POSIX Linux classifiers. The executable you produce is built for the machine you build it on, since PyInstaller does not cross-compile.

### How do I uninstall auto-py-to-exe?

The README does not document an uninstall procedure. Since it installs as a normal Python package, removal follows whatever the package manager you used supports, but the project itself gives no command for it.

## Sources

- [brentvollebregt/auto-py-to-exe on GitHub](https://github.com/brentvollebregt/auto-py-to-exe)
- [Issues](https://github.com/brentvollebregt/auto-py-to-exe/issues)
- [License: MIT](https://github.com/brentvollebregt/auto-py-to-exe/blob/master/LICENSE)
- [README](https://github.com/brentvollebregt/auto-py-to-exe/blob/master/README.md)
- [Releases](https://github.com/brentvollebregt/auto-py-to-exe/releases)

---

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