Skip to main content
← Back to list
01Issue
FeatureClosedSwamp CLI
AssigneesNone

Relationships

#1050 Native FreeBSD build for swamp CLI

Opened by josephholsten · 7/9/2026

swamp has no official FreeBSD binary or port. Users on FreeBSD must build from source or run under the Linux compatibility layer, which adds friction and isn't suitable for production use.

This feature would add FreeBSD (amd64 at minimum) as a first-class release target. Changes would be needed in:

  • The CI/release build matrix (adding a FreeBSD runner or cross-compile step)
  • Binary distribution packaging (tarball and ideally a ports-tree-compatible layout)
  • Platform detection in any install scripts

The approach would mirror the existing Linux amd64 build pipeline, adapting for FreeBSD syscall and linking differences.

02Bog Flow
✓OPEN○TRIAGED○IN PROGRESS◉CLOSED

Closed

7/9/2026, 6:42:55 PM

No activity in this phase yet.

03Sludge Pulse
Editable. Press Enter to edit.

swamp_lord commented 7/9/2026, 6:38:05 PM

Thanks for filing this — the need is legitimate, and I want to be straight about where we land.

The gap is real

swamp has no native FreeBSD binary, and today we can't produce one without forking our build pipeline. The swamp CLI ships as a single self-contained binary built with deno compile. That toolchain only emits binaries for a fixed target set:

  • x86_64-unknown-linux-gnu / aarch64-unknown-linux-gnu
  • x86_64-pc-windows-msvc
  • x86_64-apple-darwin / aarch64-apple-darwin

There's no FreeBSD target. deno compile embeds a precompiled runtime (denort) into each binary, and Deno's own release process doesn't build a FreeBSD denort — so cross-compiling to FreeBSD isn't a matrix entry we can just switch on. Deno also ships no official FreeBSD runtime upstream (long-standing denoland/deno#6774).

Why we're not going to shard the build

A first-class FreeBSD target as described here — a FreeBSD runner or cross-compile step in the release matrix — would mean building swamp outside deno compile for that one platform: a second toolchain, a second CI path, and a separate test/support surface that doesn't share code with the primary release flow.

That's not a small adaptation of the Linux amd64 pipeline; it's a parallel pipeline. The cost isn't just the initial work — it's every future release carrying a bespoke path that can break independently of the other five targets. We'd be trading reliability and release velocity on the platforms the vast majority of users run to add one we can't test the way we test the rest. That's a worse product for everyone, including FreeBSD users, who'd get a less-trustworthy binary.

The workaround (imperfect, but real)

Until Deno supports FreeBSD upstream, the path is running the Linux amd64 binary under FreeBSD's Linux compatibility layer:

  • Linuxulator (linux/linux64 kernel modules) — run the Linux binary directly, or
  • a Linux jail, container, or VM alongside your FreeBSD host.

You already flagged this as friction that isn't ideal for production, and that's fair — it's a workaround, not parity. I won't oversell it.

What would actually unblock this

The realistic unblock is upstream: if Deno adds FreeBSD to deno compile's target set (and ships a FreeBSD denort), a native swamp build becomes nearly free and we'd revisit immediately — one more matrix entry rather than a second pipeline. That's the lever worth pushing on (denoland/deno#6774), and we're glad to track it from our side.

Marking this as wontfix for now on the shard-our-own-build path, with the upstream dependency noted. Thanks again for the detailed writeup — the packaging/ports notes will be genuinely useful the day the toolchain supports it.

swamp_lord commented 7/9/2026, 6:42:55 PM

Closing as wontfix on the shard-our-own-build path, per the disposition above. Happy to reopen the moment Deno adds a FreeBSD target to deno compile upstream (denoland/deno#6774).

Sign in to post a ripple.