Repository navigation
Three files, one per platform. All are self-contained: each carries a minimal Rust toolchain and the JavaScript runtime, so the first app can be built on a machine with nothing installed beyond the OS and its C toolchain.
| Platform | File | Notes |
|---|---|---|
| macOS arm64 | Deepnest-0.1.1-arm64-mac.dmg |
ad-hoc signed, not notarized — right-click → Open the first time |
| Windows x64 | Deepnest-0.1.1-x64-windows.exe |
not signed at all — SmartScreen asks once; one file, nothing to install |
| Linux x64 | Deepnest-0.1.1-x64-linux.tar.gz |
not signed at all; a tarball because that is the archive format that carries the executable bit — glibc, not musl |
A .sha256 sits beside each download.
The Linux download holds one file, deepnest: extract it and run it. It is built against glibc and carries the glibc build of the JavaScript runtime, so a musl-only distribution such as Alpine is not covered yet.
What the Windows build does not do yet
The agent's bash tool refuses to run a command on Windows. Confinement there is an ACL plan plus a restricted token: the plan is derived, the code that applies it is not written, and a plan derived but never applied is no fence at all — so the call is refused rather than run unconfined. File tools, app builds and app runs do not go through that path and work.
A defect this fixes on macOS
v0.1.0's disk image never passed codesign --verify --strict. The linker ad-hoc signs the executable, and an arm64 executable's signature declares a resource seal the .app never had, so a strict verify failed with code has no resources but signature indicates they must be present. The bundle is now re-sealed with codesign --force --sign -, which writes Contents/_CodeSignature/CodeResources, and the strict verify is an acceptance condition on both the signed and the unsigned path instead of the signed one only. The signature is still ad-hoc: this changes what the bundle carries, not who vouches for it.
Requirements
- macOS — Xcode Command Line Tools (
xcode-select --install). - Windows — Visual Studio C++ Build Tools.
- Linux — a C compiler and linker (
build-essentialon Debian/Ubuntu,base-develon Fedora).
deepnest checks for them before the first build and walks you through installing what is missing, instead of failing halfway through compilation.
How these were built
Every file was built by CI, never from a laptop, and no job stops at "it compiled".
The macOS and Windows files were built by CI from the v0.1.1 tag. The Windows job starts the executable, asks /api/health on a port moved off 4270, and requires ~/.deepnest/deepnest.token to have been minted.
The Linux file was attached after the tag was cut, and that is stated rather than glossed over: a workflow has to reach the default branch before it can be run at all, and linux.yml landed on the default branch only after v0.1.1. It was built by CI from the commit the tag points at, with only that workflow added — the same tagged source, built by CI. Its job packs the tarball, unpacks it again, starts the executable it just packaged, asks /api/health and gets {"status":"ok","version":"0.1.1"}, and requires the token it mints to be 0600.