BareProxy Runs on Linux, macOS and Windows, and One Plugin File Runs on All of Them
Every BareProxy release comes in five builds: Linux on x86-64 and ARM, macOS on Apple silicon and Intel, and Windows on x86-64. The plugins don’t come in builds at all. Each one is a single WebAssembly file, and that file runs on every one of them.
Here’s where each platform stands today, as of 0.5.0, and why the plugins never need a per-platform version.
Five Builds From One Source
BareProxy’s core is Go, with no C code anywhere in it. That makes every build a single static binary. Nothing to install next to it, no libraries to match. The Linux binaries run on any distribution.
| Platform | Download | How it’s tested |
|---|---|---|
| Linux, x86-64 | bareproxy_linux_amd64.tar.gz | Full test suite with race checks on every push, a live test in front of a real site, smoke test on every release |
| Linux, ARM64 | bareproxy_linux_arm64.tar.gz | Smoke test on a real ARM machine on every release |
| macOS, Apple silicon | bareproxy_darwin_arm64.tar.gz | Full test suite on every push, smoke test on every release |
| macOS, Intel | bareproxy_darwin_amd64.tar.gz | Built and checked as an Intel binary on every release |
| Windows, x86-64 | bareproxy_windows_amd64.zip | Smoke test on Windows on every release |
The smoke test runs each binary the way a new user would. It checks a config, asks explain about a request, serves a page and a 404, and reads the status. A release only goes out when all of them pass.
Where Each One Stands
Linux is home. It’s where BareProxy has run under load, in front of a real site, and where every measurement on this site was taken. Use it for anything that matters.
macOS gets the whole test suite on every change, so it’s close behind. The binaries aren’t signed by Apple yet, so macOS may ask you to allow them the first time you run one.
Windows works but has seen the least. Two things differ there. Windows has no SIGHUP, so you reload with apply instead of a signal. And the admin socket is a Unix socket file, which Windows has supported since Windows 10 version 1803. Outside Linux, history also doesn’t record which user made a change.
There’s no Windows on ARM build yet. Adding one is a single line in the release script, and it’ll come when someone asks.
Why Plugins Don’t Care About the Platform
A BareProxy plugin is compiled once, to WebAssembly. Not to Linux, not to macOS, not to Windows. The same .wasm file goes into a plugin line on any of the five builds and does the same thing.
That works because of two choices made when plugins went WebAssembly.
The runtime is wazero, written in pure Go. It ships inside every BareProxy binary, so there’s no plugin runtime to install either. On x86-64 and ARM64 it turns each plugin into native machine code when the config is checked, on all three systems. So a plugin runs at full speed whether the server is a Linux box or a Mac mini.
The interface is Proxy-Wasm. A plugin sees requests and responses, and nothing else. It can’t open a file, a socket or a process unless the config hands it one, and then it goes through the host. A plugin can’t quietly come to depend on one operating system, because it never touches one.
The plugins themselves are written in Rust and built for the wasm32-unknown-unknown target, which names no operating system at all. Each release attaches the plugin files next to the binaries. Maintenance pages, CORS, and header and rewrite rules are out now, and every later one in the plugin program ships the same way.
The One Thing That Is Per Platform
When a plugin asks the host for something, the host side of that is native code. Outgoing calls, the shared store and certificate files all live in the core, and the core is tested per platform as described above. So a plugin is as portable as the core under it. Today that means everywhere, with Linux tested hardest.
Windows is next in line for more testing, starting with running the full test suite on it on every push.