Unison Cloud Goes MIT, but Its Local-Run Guide Still Pulls Nimbus From a Private Repo

Unison Computing open-sourced the platform behind Unison Cloud on Oct. 8, releasing a worker node, a Haskell API server and the web console under the MIT licence, according to a post by Paul Chiusano. The company's earlier product, a paid way to run programs written in the Unison language on a cluster, is now something a reader can clone.

The post says Unison Cloud "turns any pool of nodes into a distributed computer, programmable with the Unison language." It gives the reason in one sentence: "We think this tech will be more useful to the world as an open source technology and hope that people build great things with it."

The four pieces

Chiusano lists four projects. Only three are new, because the fourth, the client library that defines the programming model, has been open source "for a long time," the post says.

Piece	What it does	Where it lives	Status
Cloud client	Programming model, local interpreter, cluster interpreter	Unison Share, @unison/cloud	Already open
Nimbus	Worker node, written in Unison	Unison Share, @unison/nimbus	Newly open
Cloud API Server	Cluster membership, authentication, control plane, in Haskell	GitHub, unisonweb/cloud-api	Newly open
Cloud UI	The code behind app.unison.cloud	GitHub, unisonweb/unison-cloud-ui	Newly open

The cloud-api repository is MIT licensed, shows one star and two commits on its trunk branch, and uses Consul for peer discovery according to its README. The unison-cloud-ui repository is also MIT, shows 437 commits, one star and three open pull requests. Neither number says anything about adoption; both repositories are new to the public.

What the post leaves out

The announcement does not say whether anything stays proprietary, how to run a production cluster, what the hosted service costs now, or whether the hosted service continues. It points readers who want support to [email protected].

The repository's own running-locally guide is more specific than the post. It lists Docker as the prerequisite and make as optional, then adds a catch: without a NIMBUS_LOCAL_BRANCH variable, "the Docker builds pull Nimbus from a private Share repo, which requires credentials." The Makefile expects those at ~/.local/share/unisonlanguage/credentials.json, normally written by running auth.login in the Unison codebase manager.

That sits awkwardly beside a post that calls Nimbus newly open. The guide may predate the release; the repository shows two commits and no date, so the page alone does not settle it. Someone who clones the repo today and runs the default make build should expect to be asked for a login until the guide is updated or the repo says otherwise.

How this fits the company's earlier choices

In May 2024 the same company open-sourced Unison Share under MIT and wrote that "our company's main product is Unison Cloud." That post described Cloud as hosted by the company or installed in a customer's own VPC or on-premise.

In October 2025 a bring-your-own-cloud post offered free personal use "up to 10 node clusters or 160 cores" and free trials for commercial users, and said the setup needs only S3-compatible storage. The new post does not say whether those licence terms still apply or whether the MIT release replaces them.

The storage side has its own dependency. The Oct. 8 post describes transactional storage backed by DynamoDB and object storage backed by S3, so a self-hoster outside AWS is left to find substitutes. The fakecloud AWS emulator and the durable-execution libraries covered earlier on this site sit in the same territory, but neither is mentioned by Unison.

What to watch

The next marker is the cloud-api repository itself: a third commit that updates the local-run guide would show whether the Nimbus credentials step is a leftover or a real gate. The post gives no date for either.