Should bun-v1.3.14.exe x serve -s . "just work" and not complain ...

[stdedos]

error: bun is not installed in %PATH%

Please run the following command, or double check %PATH% is right.

    powershell -c "irm bun.sh/install.ps1|iex"

assuming that bun-v1.3.14.exe is indeed in the same directory?

I have a habit of naming my "portable files" also with the version number - so that I can recognize their version faster than trying to figure out what their version argument is

[mg1986jp]

The x subcommand (bunx) internally tries to locate and spawn bun by name. When you rename the binary to bun-v1.3.14.exe, it can't find bun in PATH anymore and throws that error.

Bun doesn't inspect its own executable path for this — it just looks for bun in your system PATH. So renaming breaks bunx, bun install, and anything else that needs to spawn a child bun process.

If you want to keep versioned copies, you could keep the original name and use a wrapper or symlink:

# symlink approach
New-Item -ItemType SymbolicLink -Path "bun.exe" -Target "bun-v1.3.14.exe"

Or just keep it as bun.exe in a versioned folder like bun-1.3.14/bun.exe.

[Adit-Jain-srm]

No, bun-v1.3.14.exe x serve -s . won't work because bun x (which runs bunx) needs to find the bun executable in PATH — it's not designed to run as a standalone portable binary with a custom filename.

The error is because bunx internally tries to locate bun in PATH (it shells out to itself for package management), and renaming the exe breaks that lookup.

Solutions for portable/versioned usage:

1. Create a directory per version and add it to PATH:

mkdir C:\tools\bun-1.3.14
copy bun-v1.3.14.exe C:\tools\bun-1.3.14\bun.exe
$env:PATH = "C:\tools\bun-1.3.14;$env:PATH"
bun x serve -s .

2. Use a symlink/hardlink named bun.exe:

New-Item -ItemType HardLink -Path .\bun.exe -Target .\bun-v1.3.14.exe
.\bun.exe x serve -s .

3. Use a version manager like proto or bvm which handles this automatically:

proto install bun 1.3.14
proto use bun 1.3.14
bun x serve -s .

The core issue is that Bun expects its own binary to be named bun (or bun.exe on Windows). Any rename breaks internal self-referencing.

@stdedos For your version-tracking habit, the symlink/directory approach gives you both — the original named file for identification plus a bun.exe link for actual execution.