Dropserver Progress - October 2025
This is the progress report for Dropserver for October 2025. The previous report is here.
This month I continued thinking about how to make ds-host easy to install, but I also got to work on some real improvements. In particular I found out that my MacOS build of ds-dev was broken…
Fixing Releases to Support arm64
My Github Action that builds the Dropserver releases used the macos-latest image to build ds-dev. That image used to be Intel-powered. At some point Github decided to make it an arm64 machine.
The result: my builds of ds-dev that stopped working on Intel.
Since I had been wanting to release an arm64 version of ds-host and ds-dev for Linux to support the Raspberry Pi and other SBCs I decided to rewrite the Github Actions to fully support multi-arch and multi-OS releases.
I also separated the building of release artifacts from the actual release, allowing me to build for platforms even if I don’t release them. This lets me test on unreleased platforms without having to build on that platform.
See all these commits.
0.14.2 Release for Linux/Arm64
Dropserver 0.14.2 includes binaries for Linux-arm64 for ds-host and ds-dev.
I tested ds-host out on my old Raspberry Pi 4B (4 Gigs of RAM) and it worked fine. Sandbox start times are a bit slower (300ms instead of 150ish), but that’s still highly usable. So now Dropserver works on a small cheap SBC! Nice.
0.14.4 Release ds-host for MacOS on Intel and Arm64
I have long had a ds-dev build for Mac, and while working on the Tailscale integration I tested ds-host locally on my Mac to save time. So I have some confidence that Dropserver works fine on the Mac.
I only had to make it so the “linuxy” bits don’t show thorough on the Mac and it was ready to go. Commit 4a6803a disables cgroups and bwrap on darwin.
The rest was mostly about docs, and me learning how to run a service on a Mac. Launchd is quite different from systemd. It likes to quietly do nothing that you’re asking it to do instead of printing an error.
For now the docs show how to run ds-host as your main user. This is of course not ideal, and it leads me to the next thing:
Sandboxing on MacOS
I talked last month about how I am moving away from two-layer (Deno + bubblewrap) sandboxing of app instances. I’m trusting Deno more as the primary sandbox and I think a sandbox around ds-host and its Deno sub-processes makes more sense as the secondary sandbox.
This was a good opportunity to experiment with the Mac’s sandboxing abilities.
Unfortunately I didn’t get far.
sandbox-exec should be very effective as it’s pretty low-level, but it’s not easy to get it working. If you block everything by default there is a lot of work needed to figure out what needs to be allowed for the program to work. I didn’t have the time to go all the way with this so I’m punting.
If I can’t get that to work I can at least start with an allow by default, and then restrict reading and writing to the user’s files outside of the ds-host data dir. That would protect the user’s stuff at least.
Launchd also has some capabilities, like RootDirectory, which is essentially chroot, but I haven’t played with that, and it’s likely not the way to do things anymore.
Finally it seems the way things are done now is through the App Sandbox. ds-host itself would call the Mac’s sandboxing features to specify how it wants to be contained. Although this answer indicates it’s a very coarse kind of sandboxing, so less valuable (but easier to get right no doubt!)
If you are knowledgeable about sandboxing things on the Mac and you want to help out, please reach out!
Work on ds-dev for Windows
Two years ago I tried to get ds-dev to work on my Windows machine. I was traveling recently with my Windows Laptop so I decided to take another stab at it.
First I had to bring that branch up to speed. It was over 150 commits behind. Fun.
Then I set things up so I can test the code from a Linux WSL2 instance of Debian in addition to normal Windows OS. That way as I mess around to get things to work on Windows I can verify that the tests still pass on Linux.
I made some progress on the smaller more obvious fixes. Almost everything is a question of how to handle paths, really.
But the real crux of the problem is centered on the Deno sandbox. The problem is that there are paths everywhere: some get passed to Deno via cli args, some are written to the import map, some are written to JS code as imports, some fetch files from Go’s virtual filesystem, some from Deno, etc… In each case I’m not completely clear what format (slash type, “C:\\”??) is understood or expected.
So there is a lot more work to do there, but one day I hope ds-dev, and then ds-host will work on Windows natively.
Here’s to Another Mid-Month Update
And that is all for October. I am quite happy with the progress I made. I have releases for hardware that is more likely to be available and familiar to people, making Dropserver more accessible. Installation process is still bad, but I’m on it.
I said a month ago I’d try to write this sooner after the end of the month. Looks like I failed. Oh well.
I’m excited to share the “cleanup on aisle 6” type of work I’m doing in November. See you in early December! Or mid-December.
