Install vibe
01vibe is one program with no runtime to install. On Windows you download an archive and unpack it; on any platform with a Rust toolchain you build it from the source. When it is done, one command prints the version.
Install vibe on this machine: on Windows from the latest release archive at github.com/vibevm/vibevm, otherwise by building the source checkout with its first-run script. Then open a new shell and confirm that `vibe --version` prints a version.network access to github.com; on a platform other than Windows, git and a Rust toolchain
vibe --version prints vibe 1.0.0 in a new terminal, and vibe self doctor reports no problems
vibe --versionvibe self doctor
What happens
03On Windows the agent downloads the release archive, unpacks it, and runs its installer script. The script imports the binary into vibe's own managed folder under ~/.vibe/opt, marks it active, and adds one folder of small launcher scripts to your user PATH. Everywhere else the agent clones the source repository and runs its first-run script, which builds the program and installs it through the same manager. Either way, the result is the same layout: versions under ~/.vibe/opt/vibevm/, launchers in ~/.vibe/opt/bin/, and a pointer that says which version is current.
04$VIBEVM_INSTALL_ROOT(the install BASE) defaults to~/.vibe→ root~/.vibe/optin normal use (owner ruling 2026-08-20, the release-1.0 install path; until then the default base was the bare home dir →~/opt). An explicit override keeps its meaning —<override>/opt— and one env var still relocates everything; tests pin it to a temp dir. A managed binary keeps recognising its own root by shape (the trailingoptcomponent), so both generations of store keep working.
05vibe runs on Windows, macOS and Linux. The one-line cold start is a script at a stable address, https://vibevm.org/install.sh for Bash and install.ps1 for PowerShell: it downloads the release manifest, verifies a small bootstrap binary by size and digest, and that binary verifies and installs the full bundle. Package managers such as Homebrew and WinGet come later.
06 Decision: M0 builds and runs on macOS, Linux, and Windows.
07 Stable endpoints provide one-line native cold start: Bash for Linux/macOS/WSL and PowerShell for Windows. Each bounded script downloadsDISTRIBUTIONS.json, verifies a small rawvibebootstrap by size/SHA-256, then that Rust binary verifies and atomically installs the full bundle.
08 The scripts are shipped release assetsinstall.shandinstall.ps1and are exposed by stablehttps://vibevm.org/install.*redirects. Homebrew, WinGet, and CMD installers remain outside this slice.
By hand
On Windows
091. Download vibe-<version>-windows-x86_64.zip from the releases page of github.com/vibevm/vibevm.
102. Unpack the archive into a folder of your choice.
113. In that folder run the installer:
134. Open a new terminal, so that the changed PATH is read.
145. Check the result:
16The archive also contains SHA256SUMS.txt. Compare the digest of vibe.exe with the line in that file before you run the installer. The installer does the same check.
From the source, on any platform
171. Install git and a Rust toolchain. OpenSSL is not needed.
18
A from-source build needs git, a Rust toolchain (rustc + cargo,
stable ≥ 1.93, edition 2024 — via rustup so the pin resolves), and a
system linker / C toolchain (Windows: VS Build Tools; macOS: Xcode CLT;
Linux: build-essential). A native binary install needs none of those;
its bootstrap uses only the platform download/TLS facilities.
192. Clone the repository: git clone https://github.com/vibevm/vibevm.git and enter the folder.
203. Run the first-run script: bash tools/first-run.sh on Linux and macOS, .\tools\first-run.ps1 on Windows. It builds the program, installs it into the managed store and sets up the launchers.
214. Open a new terminal and run vibe --version, then vibe self doctor.
22Later, vibe self update moves the installation to the newest release, and vibe self reinstall downloads the current one again. vibe self ls lists the versions on the machine, and vibe self rollback returns to the previous one.
23self install <selector>— from a source execution, build the selected ref; from a managed binary execution, an explicitX.Y.Zinstalls that native release. Flags:--release/--profile <debug|release>(source lane);--mirror <gitverse|github>(force the source lane);--force(always allocate a fresh immutable#N).
Where things go
24vibe keeps everything it owns under one folder in your home directory, ~/.vibe/: the installed versions and their launchers under opt/, the machine store of fetched packages under cache/, registry clones under registries/, and your settings files. Nothing is written anywhere else, and the whole folder can be moved by setting the environment variable VIBE_SETTINGS.
25 The settings home is~/.vibe(owner, 2026-08-20). This document previously named~/.config/vibe/config.toml; the code has treated~/.vibeas canonical all along and the XDG path only as a legacy location an operator is invited to migrate out of. The correction is to this document, not to the tree.
26The installer never overwrites a running binary and never edits your PATH twice: it adds one entry, guarded by a marker, and leaves the rest alone.
27
never clobber (only our entry is added; the rest of PATH is
preserved),
Edge cases and rules
28If vibe --version prints nothing in the terminal where you ran the installer, open a new one: the PATH change applies to new shells only.
29A ready-built binary from anywhere can join the managed store without a toolchain: vibe self import ./vibe.exe --tag 1.0.0 --use.
30self import <PATH> --tag <X.Y.Z>— put a legacy READY-BUILT localvibeexecutable into the inventory as an immutabletag:instance, reusing the store/placer/lock/state machinery (built 2026-08-20 for the 1.0.0 distributive; the install.ps1 of the zip calls it instead of duplicatingstate.toml). Local by construction: no network, no signature machinery — the file is streamed through SHA-256 once, and that digest drives idempotence: same tag + same digest reuses the instance; same mutable tag + different digest creates a new local#Nbeside the preserved old one.--replace-candidateremains compatibility spelling. Optional--commit,--profile(defaultrelease); inactive by default —--useruns the same complete shim/PATH/pointer/advisory-HOME activation as every other lane.
31Building an arbitrary git ref is running arbitrary code, as with any build from source. Build from the repository and the branches you trust.
32 Building an arbitrary ref is arbitrary code execution — inherent to a build tool the user invokes deliberately, and accepted.