FlakeHub separates version requirements from locked flake sources

A commit identifies source precisely, but it does not tell a consumer which future commits are intended to be compatible. Flake inputs following a branch can move to whatever that branch contains next. Pinning a revision avoids that movement while leaving the author to decide each update manually. Version requirements offer another way to describe the intended update policy.

Determinate Systems introduces FlakeHub in its August 22 announcement. The service combines flake discovery and publishing with semantic-version selection. Its important architectural distinction is that a version requirement guides selection, while the resulting lock entry identifies the selected source. Those two pieces have different jobs.

I value Nix because it records the inputs behind a build or system declaration. That makes update policy a separate concern from rebuilding the current declaration. A service can help choose the next input without making the existing lock file an instruction to keep changing on every build.

A requirement expresses an update policy

The launch article describes flake URLs containing a version requirement. It supports wildcard forms and operators such as ~ and =. The service interprets those requirements to select a published flake version that matches.

The announcement uses Nixpkgs as an example. A requirement for 0.2305.* stays within that version series when the input is updated. Its example input declaration is small:

{
  inputs.nixpkgs.url =
    "https://flakehub.com/f/NixOS/nixpkgs/0.2305.*.tar.gz";
}

This is the input portion of a flake declaration. A complete project still needs its outputs and any other required inputs. The URL states a selection policy, while the consuming project's output function determines what to build or configure from the resulting source.

The wildcard belongs to the URL string. It is not a Nix-language operation that discovers matching Git revisions locally. FlakeHub provides the interpretation behind the HTTP endpoint. That matters when explaining where version selection actually happens.

Semantic versioning also remains a statement by publishers about their releases. Naming a version as a patch does not mathematically prove that a consumer's configuration will continue to work. The service supplies a vocabulary and resolution mechanism for compatibility policy. It does not infer every downstream dependency on package or module behavior.

A lock entry records the selection

The announcement distinguishes the requested source from the locked source in flake.lock. Its example retains the original requirement and records a resolved tarball URL with revision metadata and a NAR hash. That division lets a project remember both why the source was selected and which source it selected.

A later update can reevaluate the requirement and choose a newer matching version. An existing lock entry, however, represents the prior resolution. This is what lets version flexibility coexist with an exact input description. The update operation changes the selection deliberately, rather than treating every realization as another request for the latest publication.

This distinction is useful during review. A change to the original URL can broaden or narrow the allowed version series. A change to the locked source can move to another publication within an unchanged policy. Both can affect a build, but they communicate different decisions.

The launch article's URL examples illustrate this mechanism without requiring Nix to understand semantic versions as a new core source type. HTTP remains the transport and the service chooses the corresponding tarball. The lockable tarball protocol supplies the connection between a mutable selection endpoint and a fixed result.

The HTTP protocol supplies the immutable reference

The Nix 2.17 protocol documentation explains that connection directly. A server can return an HTTP Link header whose relation is immutable. The linked reference must identify a tarball flake suitable for recording in a lock file.

The protocol lets the user request a moving endpoint such as a latest-version URL while Nix records a URL intended to keep the same contents. Without this protocol, the documentation says users are responsible for making sure a tarball URL always supplies the same contents. The server-provided immutable reference makes that intended stable identity explicit.

The launch article describes FlakeHub using a redirect and link metadata to resolve its version endpoint. Its resolved URL includes a UUID as well as revision information. That is the service's concrete naming arrangement, built on the general tarball mechanism.

This matters because the capability is not exclusive to one registry's naming scheme. The Nix protocol allows another HTTP service to return an immutable tarball reference according to a different selection rule. Semantic versions are one policy that can operate above the protocol.

I find that boundary well chosen. Nix can handle a source identity and verify archive contents without having to embed every publisher's release policy. A distribution service can offer richer selection while still returning a result through an established fetching contract.

Content hashes and revision metadata have different authority

The protocol permits attributes including narHash, rev, and revCount in the linked reference. Its documentation states that Nix checks the unpacked tarball against narHash. That is a content check on the selected source representation.

The same document explicitly says Nix does not check rev and revCount. Those fields can be useful when the tarball mirrors a Git-backed source, but their presence is not a separate verification that the archive came from a particular repository history. Treating every metadata field as cryptographic evidence would overstate the protocol.

This gives a precise account of the trust relationship. FlakeHub resolves a requirement and supplies source metadata. A content hash lets Nix detect contents that disagree with the recorded hash. The meaning of a release version and its asserted relationship to upstream history still depend on the publishing system.

The protocol also defines lastModified for a tarball as the timestamp of its newest contained file. That value is therefore archive metadata with a specified interpretation. It is not automatically the time the service published the archive or the time a consumer resolved it.

These distinctions are useful for tooling that displays source information. A timestamp or revision can help a human understand a lock entry, while the hash supports a different validation task. A robust explanation should identify which field supplies which evidence.

Publishing connects releases to discoverability

FlakeHub's launch workflow uses GitHub Actions to publish flakes. The announcement describes publication on semantic-version tags and a separate rolling strategy. The tagged strategy gives publishers a direct way to associate their existing release decisions with versions consumers can request.

A rolling strategy uses a version prefix with a commit count and revision information. That supplies a generated version identity for a moving development stream. It remains a policy choice, with different expectations from a project that deliberately curates each tagged release.

The service also adds search by publisher and project, with descriptions and tags. That addresses discovery, which a source hash alone cannot provide. A consumer needs to find an appropriate flake before deciding which version policy should govern its use.

Discovery and compatibility remain separate functions. A search result can identify a project whose description matches a requirement without proving that its outputs fit another project's needs. The selected flake still has an interface that its consumer must use correctly.

The announcement also lists a dedicated command-line client among planned additions. At launch, the described consumption mechanism already uses ordinary Nix flake commands against the service's URLs. That is a useful distinction for automation. Resolving an input does not require assuming that a proposed search client has already shipped, and a future client would not replace the lock file's role in recording source selection.

Unlisted is not private at launch

The announcement says launch-time flakes are public or unlisted. Unlisted flakes do not appear on the website, but Nix can still use them. Private organization-only access is listed as future work. Omitting a flake from discovery therefore should not be read as an authorization boundary.

That qualification matters to adoption because a publishing system handles source distribution as well as metadata. A project deciding whether to upload a flake needs to know who can obtain it, independently of whether it appears in search. The launch account makes that limitation explicit.

For a configuration maintained through pinned inputs, FlakeHub adds a documented selection policy above those pins. A requirement describes eligible versions, the service resolves a publication, and the lock file records the resulting source. The HTTP protocol preserves those separate responsibilities without requiring a version range to stand in for an immutable build input.