# NixOps4: a Rust rewrite of NixOps for declarative deployments

> An in-development project intended to replace NixOps 2, fixing its resource syntax and giving deployment projects a stable interface to plug their own resource implementations into. It is written in Rust and reuses the Nix module system and OpenTofu.

**nixops4/nixops4** — Deploy with Nix and manage resources declaratively

- Repository: https://github.com/nixops4/nixops4
- Stars: 951 · Forks: 21
- Language: Rust
- License: LGPL-2.1
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/nixops4-nixops4

## A replacement for NixOps 2 that is not finished yet

NixOps4 is a rewrite of NixOps 2, the earlier Nix deployment tool. The project description is two verbs: deploy with Nix, manage resources declaratively. The documentation states the intent plainly, that the project is intended to replace and improve on NixOps 2, and that it fixes a number of structural issues through a rewrite from first principles.

A rewrite from first principles is a bigger claim than a patch release, and it is worth separating that claim from what is verifiable. The verifiable parts are these. The code is Rust, the stated goal is a maintainable code base in Rust, and the repository is laid out accordingly with a rust/ directory at the top level next to the Nix parts. The licence field on the repository says LGPL-2.1, and the default branch is main.

The unverifiable part is the completion. The documentation carries a status line that reads, in development, and the repository has no GitHub releases at all, so there is no version to pin, no changelog of user facing changes, and no compatibility promise you could hold anyone to. The last push was on 2026-10-16, so the tree is being worked on, but a moving target with no release tags is a different thing from a tool you can deploy from.

The project has its own site at nixops.dev, and the README points there for the current documentation. The README in the repository itself is short, which is unusual for a deployment tool and consistent with a codebase that is still being designed.

## The six goals, and what each one commits the project to

The goals list is the most informative part of the documentation, and each line is a design decision that the rewrite has to honour.

Support for stateless and stateful deployments comes first, which tells you the tool is meant to cover both a fleet of identical machines and machines with data on them. The documentation does not say which resources implement which kind, and that gap is the point to keep in mind when you evaluate it: the distinction is a stated goal rather than a described feature.

Fixing the NixOps resource syntax is the second goal, and it is the one with the widest blast radius. Resource syntax is the interface between a deployment project and the resources it manages, so changing it touches every project that already exists. The third goal, a stable interface for defining resources, is the counterweight: the idea is that a resource developer has a well-defined task and minimal maintenance afterwards. A stable interface is also what makes the fourth goal possible, which is that deployment projects can choose or provide their own resource implementations. That is the interesting structural bet of the whole project. Instead of one fixed catalogue of resources shipped by the tool, the resource layer becomes pluggable, and the tool provides the contract.

The last two goals are about sustainability rather than function. Existing technologies are reused, specifically the module system and OpenTofu, and the code base is kept maintainable in Rust. Reuse is the cheaper path and the faster one, and it also means NixOps4 sits on Nix's module system rather than inventing a configuration language of its own.

## A repository split by language and by role

The top level entries show how the project is organised, and the names are doing the describing. There is a rust/ directory for the Rust code, a nix/ directory for the Nix side, dev/ for development tooling, doc/ for documentation, and test/ for tests. The rest is the standard Nix packaging surface: flake.nix and flake.lock at the root, a package.nix for building the project as a package, and an .envrc for direnv.

Two small entries say something about the state of the work. The .vscode/ directory is present, and the README has a section for VS Code and rust-analyzer, which tells you the author expects to work on the project in an editor rather than only in a terminal. The bash-completion-wordbreaks.patch file is a patch applied to the Bash completion machinery, which is the kind of detail that shows up when a CLI needs its completion to break words in a particular way.

The absence of entries is informative too. There is no CHANGELOG.md, no CONTRIBUTING guide, and no release automation visible in the top level listing, and those are the files you would expect in a repository that had ever cut a version. The combination, a working Nix flake and a Rust workspace with a test directory but no shipped releases, is consistent with a rewrite that is still being shaped rather than one that is being operated.

For someone reading the code, the split between rust/ and nix/ is the natural place to start, because that boundary is where the tool meets the Nix ecosystem it intends to reuse.

## One command opens the development environment

The hacking section of the documentation is short because the flake does the work. Running the following opens a shell with the dependencies already loaded, and installs pre-commit so that formatting is applied automatically before each commit:

```bash
$ nix develop
```

That is the entire setup instruction, and it is a good illustration of the project's stated approach. Rather than a toolchain document listing language versions, a package manager to install, and a formatter to configure, the flake supplies the environment. The .envrc file in the repository root means the same environment can be loaded automatically by direnv as you move between directories, which is the mechanism most people use to keep a Nix dev shell attached to an editor session.

The one documented problem is the editor integration. If the rust-analyzer extension fails to work, the fix is to make sure the devShell was loaded into VS Code, either through the Nix Env Selector or through direnv. In practice that means the language server is only as available as the environment behind it, and an editor opened outside the shell will show no diagnostics even though the code compiles.

The pre-commit hook is worth noting for a different reason. Automatic formatting on commit is the project's answer to keeping a Rust code base readable while it is being rewritten, and it means contributors do not have to agree on a formatting policy in review.

## The resource interface is the contract, and the contract is the risk

Because the fourth goal lets a deployment project supply its own resource implementations, the interface between the tool and the resources is the load bearing part of the design. Everything else follows from it. A resource developer is given a well-defined task, and the expectation is minimal maintenance afterwards, which is a promise about stability rather than about features.

That design has an obvious upside and an obvious cost. The upside is that the tool stops being the bottleneck for new infrastructure types. A project with an unusual cloud, a database engine or a device fleet can implement that resource itself without waiting for an upstream release, and it does so against a documented interface rather than by patching the tool. The cost is that the interface has to be genuinely good before anyone trusts it with that responsibility, and interfaces are the hardest part of a rewrite to get right, because the mistakes are only visible once other people depend on them.

This is where the goals interact. Fixing the resource syntax and stabilising the interface are the same problem seen from two sides: the old syntax is what is being replaced, and the new one is meant to be the stable surface. A migration story is therefore the missing piece in the documentation, since it does not describe how an existing NixOps 2 project would move to the new syntax, or whether the old and new resource formats can coexist during a transition. The documentation is also silent on the OpenTofu and module system reuse beyond naming them as the technologies being reused, so the exact degree of compatibility is not something you can read off the README.

If you are an existing NixOps 2 user, that gap is where you should look for detail before you commit to anything.

## Licence, credits and the state of the repository

The licence field on the repository says LGPL-2.1, a weak copyleft licence. For a deployment tool that is mostly consumed as a binary and a set of Nix expressions rather than linked into someone else's application, the practical difference between LGPL and MIT is small, but it is worth reading the terms yourself if you intend to modify and redistribute it. This is a description of the licence, not advice on how to apply it.

The credits section is unusually specific for a project at this stage. It thanks the NixOps 1 and 2 authors and maintainers for exploring the domain, and it thanks the Fediversity project specifically for its support in pushing NixOps over the bump that became NixOps4, and for its commitment to giving back to the Nix community. That is a hint about the project's social base: it is being developed inside the wider Nix community rather than as a commercial product, which is consistent with the LGPL choice and with the decision to reuse the module system and OpenTofu instead of building new infrastructure.

The project site is nixops.dev and the repository is nixops4/nixops4 on a main branch. The last push was on 2026-10-16 and the repository is not archived, and there are no GitHub releases. Taken together, the state of the tree is that of a serious rewrite with real momentum and no shipped version, which is a reasonable thing to watch and an unreasonable thing to depend on this quarter.

## Conclusion

NixOps4 is worth following rather than adopting today, because the documentation states its status as in development, the repository publishes no GitHub releases, and no stable version exists to pin. It suits a team that already runs NixOps 2 and wants to contribute to a rewrite of the resource interface, and it does not suit anyone who needs a deployment tool to run in production this quarter. Verify first that the resource syntax and interface you depend on are the ones the rewrite is changing, by reading the goals in the project documentation, and check the nix develop shell before writing any code, since a rust-analyzer that fails to load is the first thing the project itself warns about.

## FAQ

### What is NixOps4 and how does it relate to NixOps 2?

NixOps4 is a rewrite intended to replace and improve on NixOps 2, fixing a number of structural issues through a rewrite from first principles. It is written in Rust and the project documentation marks its status as in development.

### How do I set up a development environment for NixOps4?

Running nix develop opens a shell with the dependencies and installs pre-commit for automatic formatting. If rust-analyzer fails in VS Code, the project documentation says to make sure the devShell was loaded through the Nix Env Selector or direnv.

### Does NixOps4 support stateful as well as stateless deployments?

Support for both stateless and stateful deployments is the first stated goal of the rewrite. The documentation lists the goal but does not describe which resources implement each kind, and the repository publishes no releases to check against.

### Can a deployment project use its own resource implementations with NixOps4?

Yes, that is one of the stated goals, together with providing a stable interface for defining resources so resource developers have a well-defined task. The documentation names the goal but does not yet document the interface itself in detail.

## Sources

- [Issues](https://github.com/nixops4/nixops4/issues)
- [License: LGPL-2.1](https://github.com/nixops4/nixops4/blob/main/LICENSE)
- [nixops4/nixops4 on GitHub](https://github.com/nixops4/nixops4)
- [README](https://github.com/nixops4/nixops4/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nixops4-nixops4