Problem
SpacetimeDB currently supports the following C# module build paths:
- .NET 8 with
wasi-experimental, supported on Windows, Linux, and macOS.
- .NET 10 with
NativeAOT-LLVM, supported on Windows and Linux only.
.NET 8 reaches end of support on November 10, 2026. After that date, macOS users building C# modules will be left behind using a .NET version that no longer receives support.
The docs currently state that .NET 10 is unsupported on macOS and recommend using a Linux VM or container as a workaround. We can improve this experience.
Options
1. Build NativeAOT-LLVM binaries for macOS ourselves
This is likely the worst option. It is not trivial, and other projects that depend on NativeAOT-LLVM have not taken this route.
2. Use a local Linux container from the CLI on macOS
Add Docker, OrbStack, or another container/VM runtime as a dependency for macOS users building C# modules. The CLI would start a Linux container with dotnet and the WASI SDK, run dotnet build inside the container, copy the resulting WebAssembly artifact back to the host, then clean up the container.
This should be reasonable to implement, but it introduces a third-party virtualization dependency that users must install manually. The Linux image would likely be over 1 GB, so the first run would be slow. The CLI would need to explain the dependency, image download, build environment, and cleanup behavior clearly.
3. Add a cloud build service
We can package the C# module project, upload it to a SpacetimeDB build service, do the build and send the compiled WebAssembly artifact back to the user.
This is probably the best user experience for users who are online and comfortable sending their source code to us. However, it requires us to build and operate a new service. We would need to handle sandboxing, dependency restore, privacy, logs, abuse prevention, cost controls, caching, and reproducibility.
4. Offer official Linux container image
Publish and document an official Linux container image for C# module builds. Users would run the build manually inside that environment.
This is less polished than CLI-managed containers (option #2), but it offers a specific simpler supported workaround and makes it easier for the user.
Problem
SpacetimeDB currently supports the following C# module build paths:
wasi-experimental, supported on Windows, Linux, and macOS.NativeAOT-LLVM, supported on Windows and Linux only..NET 8 reaches end of support on November 10, 2026. After that date, macOS users building C# modules will be left behind using a .NET version that no longer receives support.
The docs currently state that .NET 10 is unsupported on macOS and recommend using a Linux VM or container as a workaround. We can improve this experience.
Options
1. Build NativeAOT-LLVM binaries for macOS ourselves
This is likely the worst option. It is not trivial, and other projects that depend on NativeAOT-LLVM have not taken this route.
2. Use a local Linux container from the CLI on macOS
Add Docker, OrbStack, or another container/VM runtime as a dependency for macOS users building C# modules. The CLI would start a Linux container with dotnet and the WASI SDK, run
dotnet buildinside the container, copy the resulting WebAssembly artifact back to the host, then clean up the container.This should be reasonable to implement, but it introduces a third-party virtualization dependency that users must install manually. The Linux image would likely be over 1 GB, so the first run would be slow. The CLI would need to explain the dependency, image download, build environment, and cleanup behavior clearly.
3. Add a cloud build service
We can package the C# module project, upload it to a SpacetimeDB build service, do the build and send the compiled WebAssembly artifact back to the user.
This is probably the best user experience for users who are online and comfortable sending their source code to us. However, it requires us to build and operate a new service. We would need to handle sandboxing, dependency restore, privacy, logs, abuse prevention, cost controls, caching, and reproducibility.
4. Offer official Linux container image
Publish and document an official Linux container image for C# module builds. Users would run the build manually inside that environment.
This is less polished than CLI-managed containers (option #2), but it offers a specific simpler supported workaround and makes it easier for the user.