Wasmer sandboxes stay closed until you pass --volume or --net

Everything after the bare -- belongs to your program, not to Wasmer

The CLI's contract is visible in one line. Running Python from the registry means naming a package, then splitting Wasmer's options from your program's with a bare double dash:

wasmer run python/python -- -c "print('Hello from Wasmer')"

A shell and a third party package work the same way, with wasmer/bash and syrusakbary/cowsay as the packages. Wasmer downloads the package and caches it for future runs, so the first invocation pays for the fetch and later ones start from cache. The consequence to plan around is that the cache is part of what you are shipping: a version of Python in the registry is what your users get, not the one on your machine, and the double dash is the only thing keeping a flag of yours from being swallowed by the runtime.

File and network access are opt in, which is why a first run often fails

Access is described as secure by default, with you in control of file, network and environment access, and the mechanism is two flags. A directory is granted to the sandbox with --volume, and host networking is turned on with --net when a program needs it. Both are off until you ask. So a script that reads a file from its working directory does not get one, and a program that opens a socket does not get a network, no matter how ordinary that seems from the outside. The consequence for a service that processes user files is that every directory has to be named explicitly in the command.

The three compilers are optional crates and the workspace pins them with =7.5.0

The dependency list in Cargo.toml shows how much is optional. The wasmer crate itself is declared with default-features = false, and the compilers sit beside it as optional entries: wasmer-compiler-cranelift, wasmer-compiler-llvm and wasmer-compiler-singlepass, with wasmer-compiler carrying the compiler feature. Each is pinned to an exact version with the = prefix, and the workspace behind them holds lib/api, lib/cli, lib/cache, lib/c-api, lib/napi, lib/package-sdk, lib/virtual-io, lib/derive, lib/sys-utils, lib/wasix and lib/backend-api. The consequence is that your choice of compiler is a feature selection rather than a runtime setting.

The Makefile fails loudly on a platform it does not recognise

The build is described as a matrix with four columns, compiler crossed with platform, architecture and libc, and the variables that encode the platform column are IS_DARWIN, IS_LINUX, IS_FREEBSD and IS_WINDOWS, with IS_AMD64, IS_AARCH64, IS_RISCV64 and IS_LOONGARCH64 for the architecture column. Windows is detected from the OS variable because it has no uname -s. When uname returns something else, the build stops with the message Unrecognized platform, expect Darwin, Linux or Windows_NT rather than carrying on. The consequence is narrow but real: an architecture outside that list, or a platform the script does not know, ends your build with an error instead of a fallback, and the supported combinations themselves are documented off in the docs rather than in this file.

The Rust SDK is a path dependency because crates.io publishing is disabled

While the JavaScript and Python SDKs install from a package registry, the Rust one does not. The stated reason is a source dependency: clone the wasmer-sdk repository and point your application at its rust directory, with tokio alongside it.

[dependencies]
wasmer-sdk = { path = "../wasmer-sdk/rust" }
tokio = { version = "1", features = ["macros", "rt-multi-thread"] }

Crates.io publishing is currently disabled, and the Rust setup guide is pointed to for the required toolchain and workspace patches. The consequence is that a Rust consumer has no version number to depend on. You are tracking a checkout, you supply the patches yourself, and an update to the SDK is a change you make by hand rather than a lockfile bump.

Each binding sets its own floor, from Node 20 to Xcode 27 on iOS

The SDK requirements differ per language, and the spread is wide. JavaScript and TypeScript want Node.js 20 or newer and install with npm install @wasmer/sdk. Python installs with python -m pip install wasmer-sdk, and its wheels cover macOS and Linux on Intel and ARM64, with no Windows wheel named. Swift wants version 6 or newer, supports macOS 12 and up and iOS 27 and up, and iOS apps need Xcode 27 or newer with the deployment target set to iOS 27.0 plus a local networking key in Info.plist. Browser use of the JavaScript API needs cross origin isolation on the page before worker backed execution works.

A release candidate and the final landed five hours apart on 2026-10-01

The release record is tight. v7.5.0-rc.1 was published on 2026-10-01 and v7.5.0 followed the same day, five hours later, with v7.4.2 going out on 2026-09-16. The default branch is main, the last push was on 2026-11-02, and the licence is MIT. Two consequences follow. A release candidate and the final can be hours apart, so anything that pins a version should pin the exact tag rather than a range that might resolve to a candidate. And the exact pinning seen in Cargo.toml, where internal crates carry =7.5.0, means the shipped crates are meant to move together.

Editorial conclusion

Use Wasmer when you want to run a known package from the registry without installing its toolchain, or to embed a sandbox in your own app through the JavaScript or Python SDK. Do not reach for it on Windows Python or on iOS unless you are ready to satisfy the wheel and Xcode 27 requirements, and do not plan around the Rust crate from crates.io, since publishing is disabled and you would be tracking a path dependency. Before you commit, run the exact package and flags you intend to ship, starting with the CLI command, and confirm your platform and architecture are in the supported matrix the Makefile points at.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wasmerio/wasmer on GitHub