Nix solves a different problem than Hocus. Nix lets you define a development environment, Hocus gives you a way to run it on a remote server. Right now we use Dockerfiles to let users define the packages they need in their dev env, but we would like to support Nix in the future too. Interestingly, you can use custom BuildKit syntax https://docs.docker.com/build/dockerfile/frontend/ to build Nix environments with Docker https://github.com/reproducible-containers/buildkit-nix, and that's probably what we will end up supporting.

From what I can tell, devenv [1] and devbox [2] (both built on Nix) can also deploy to remote servers.

[1] https://devenv.sh

[2] https://www.jetpack.io/devbox

There are a lot of other ways to deploy to remote servers with Nix. Many of them are NixOS-based, but some don't require NixOS at all.

Whatever way you're using Nix for developer environments, you can reuse most of that work to define a package suitable for remote deployment.

I think Nix is relevant here, because being able to run software across different machines reproducibly is one of its major selling point. I particularly like that it doesn't rely on virtualization or containerization to do that. It's up to the user to decide how to isolate the runtime environment from the host or whether they even should. Alternatively, tools building upon Nix can make that decision for them. Either way, it allows for a more flexible approach when you have to weigh the pros and cons of different isolation strategies. Development environments defined by Nix tend to compose well too, as a result of this design.

see this is the problem w/ all these devtools - i need to pair together 5 different things when i just want a reproducible, ephemeral environment

someone needs to bring a heroku-like experience but for cloud-native development

That's the mission we're on at Argonaut. I'd love to know more about how you think about it if you're up for a chat.

What are you trying to offer above and beyond GitHub codespaces?