Taubyte Tau: a self-hosted serverless workspace you deploy to your own servers

What Taubyte Tau actually is, and who it is aimed at

Tau is the Go module at github.com/taubyte/tau. The repository description calls it a "Fullstack Workspace for Humans & Machines", and the hero image in the README expands that to "fullstack workspace for humans and AI agents". The feature strip under the hero lists the concrete pieces: Functions, Web Hosting, KV Databases, Object Storage, Pub/Sub Messaging. So the product is a runtime that covers the usual serverless primitives, packaged so that you run it yourself rather than consume it from a vendor.

The topics attached to the repository tell you where the authors place it: cloud-native, serverless, paas, p2p, webassembly, distributed-systems, cdn, 5g, ai. That is a wide net, and it is worth narrowing. The relevant audience is a team that already runs servers or VMs and wants a deployment target with function execution, static hosting, key-value state, blob storage and a message bus, without assembling five separate projects. The README frames the workflow as Prompt, Local, Prod, and the two linked videos are titled "Let AI Build & Ship Your Apps With One Prompt" and "Let AI Deploy Your Taubyte Cloud With One Prompt". Whatever you make of the AI framing, the underlying claim is that the same project definition moves from a local cloud to your production machines.

It is not a general-purpose Kubernetes replacement, and the README never presents it as one. Read the feature list literally: five primitives, one workspace, your hardware.

How Tau is put together: Go services over libp2p

The dependency list in go.mod is the clearest architectural statement available. Tau depends on github.com/libp2p/go-libp2p and github.com/libp2p/go-libp2p-pubsub, plus multiformats (go-multiaddr, go-multicodec, go-varint) and github.com/ipfs/go-cid. That combination means nodes address each other as peers and messages travel over a pub/sub layer, rather than every node talking to one central API server. The repository layout backs this up: there are top-level p2p/, core/, services/, clients/, cdk/, cli/ and dream/ directories.

State and configuration use their own formats. The module pulls in github.com/fxamacker/cbor/v2 and gopkg.in/yaml.v3, and github.com/taubyte/go-sdk appears alongside github.com/taubyte/go-sdk-smartops. Functions are the WebAssembly story implied by the webassembly topic, and the go-sdk is how a function reaches the platform's services. DNS is handled in-process through github.com/miekg/dns, and there is a github.com/taubyte/domain-validation dependency for domain checks. The HTTP side uses connectrpc.com/connect, so some service interfaces are Connect RPC rather than plain REST.

Two smaller details matter for operators. github.com/go-git/go-git/v5 and gopkg.in/go-playground/webhooks.v5 mean Tau reads from Git and reacts to webhooks, which is how a push becomes a build. github.com/shirou/gopsutil/v4 means the node reports host-level metrics. The Makefile adds a memory constraint: GOMEMLIMIT defaults to 4GiB. That default is a signal about the build and test footprint, not a runtime guarantee.

Installing Tau and running your first local cloud

The README does not put an install command in the body. Its Quick Start section says the quickest way to try Taubyte is to spin up a local environment with dream, and links to the getting-started page at tau.how/getting-started/local-cloud. Deployment to your own servers and VMs is split into a manual path at tau.how/platform/deployment and an automated path with Spore Drive at tau.how/platform/spore-drive. The repository also ships a cli/ directory and a dream/ directory, and the Makefile references a tau-cli target, so the CLI is built from this tree.

Because Tau is a Go module, the build path is the one in the repository. The module declares go 1.26, so that is the toolchain floor:

go build ./...

Running that from the repository root compiles the tree, including main.go and the packages under core/, services/, p2p/ and cli/. If you only want the command-line entry point, the Makefile names a tau-cli test target, which tells you the binary is produced from the cli/ tree rather than from a separate release repository.

The README's own local flow is driven by dream rather than by hand-built binaries. The Development Environment strip shows three steps in sequence: "dream new universe", then Dream Desktop, then a console login. A universe is the local cloud; the console is where projects are created. After that the Build Your Application strip shows New project, New function, and Push to Dream. The Deploy and Run strip then shows Builds, Run function and Spore Drive deploy. Read as a tutorial, that is the intended first run: create a universe, log in, create a project, add a function, push, watch the build, invoke the function.

What you should see at each stage is not documented in the README beyond those captions. The GIFs carry the detail, and the linked documentation pages carry the rest. If you want a written walkthrough, the README points at the "Hitchhiker's Guide to Taubyte" video series, including "Local Taubyte Cloud using DreamCLI" and "Create a project using the Web Console".

For a production deployment the README gives two routes and no more. Either follow the manual deployment page, or use Spore Drive, which the Deploy strip shows as the final step after a build. Neither route is described in the README itself.

Where Tau gets awkward: operations, versions and the ee submodule

The most concrete limitation is visible in the repository layout before you run anything. There is an entry named ee, and the Makefile comments describe it as "the ee/ submodule". The same comments explain that tests tagged `dreaming && ee` are excluded from the community sweep because "a package whose dreaming tests are all tagged that way has nothing to build in this sweep". So part of the tree is a submodule with its own test path, invoked separately. If you fork or vendor Tau, you inherit that split and need to know which half you are building.

The Makefile also documents a real failure mode in its own tooling. The DREAM_PKGS variable discovers packages by grepping for `//go:build dreaming`, and the comment explains that dot-directories are excluded "because tooling keeps git worktrees there", and that including them "both fails their packages outright and runs every dreaming test twice under -p, colliding on the fixed ports the fixtures bind". Fixed ports in the dreaming test fixtures are a constraint you will meet if you run that suite in parallel with anything else on the same host.

Version cadence is another thing to plan around. The most recent release in the list is v1.1.10 from 2026-04-22, preceded by v1.1.9 on 2025-11-23 and v1.1.8 on 2025-05-01. That is roughly two releases a year, with the last push to main on 2026-08-16. The repository is not archived, but a two-per-year release rhythm means you should not expect a fix to land the week you report it.

Finally, the README is a marketing surface, not an operations manual. It does not document rollback, backup of KV or object storage, upgrade order between nodes, or what happens to running functions during a platform upgrade. Those gaps are the ones to close from the documentation site before you put anything in front of users.

Tau compared with running functions on Kubernetes

The obvious alternative for the same job is Kubernetes plus a serverless layer such as Knative, or a hosted function service. The difference in approach is structural. A Kubernetes-based stack gives you a control plane whose objects are pods, deployments and services, and a function layer that translates HTTP events into pods. You get the whole ecosystem: ingress controllers, operators, Helm charts, and a large pool of people who have debugged it. Tau instead builds its own substrate on libp2p, with peer addressing and pub/sub messaging, and its own service set for KV, object storage and messaging. There is no kubelet and no etcd in the dependency list.

That cuts both ways. On the positive side, Tau's node model is meant to be lighter to stand up than a cluster, and the same project definition moves from the local universe to production machines. On the negative side, you are adopting a smaller ecosystem. When a Tau node misbehaves, the debugging surface is libp2p, CBOR-encoded state and Tau's own service code, not a decade of Stack Overflow answers about CrashLoopBackOff. If your team already runs Kubernetes well, the marginal benefit of Tau's runtime is smaller, and the operational cost of learning a peer-to-peer control plane is real.

The honest split: pick Tau when you want the five primitives on your own hardware with minimal cluster machinery, and pick a Kubernetes-based serverless layer when you want to reuse existing cluster tooling and hiring pool.

Licence, upgrade cost and what to check before you commit

Tau is BSD-3-Clause, and the README points at the LICENSE file for the text. That is a permissive licence: it allows use, modification and redistribution, including in closed products, provided the copyright notice and disclaimer are kept. It does not impose a copyleft obligation on your application code. The one thing the licence text does not settle is the ee submodule, which sits inside the same repository tree. Its own licence terms are not stated in the README, so check the ee directory directly before you assume the whole tree is BSD-3-Clause. Nothing here is legal advice; read the files.

Upgrade cost follows the release cadence. With releases roughly every six months in the list above, upgrades are infrequent enough to be events rather than routine. The README does not describe a rolling upgrade procedure, a supported version skew between nodes, or a migration path for stored data. That means the practical upgrade plan is: pin a version, read the release notes for the version you are moving to, and test the move on the local cloud before touching production.

Build cost is bounded by the Go toolchain and the memory setting. The Makefile sets GOMEMLIMIT to 4GiB by default, which you can override when building or testing. The test targets are split, with `make test` running the untagged suite and separate targets for dreaming, raft, docker and container runs. If you plan to contribute or to run the suite in CI, budget for the container-based targets as well as the plain Go ones.

Editorial conclusion

Adopt Tau if you want a serverless surface (functions, hosting, KV, object storage, pub/sub) on machines you own, and you are comfortable with a Go codebase and a peer-to-peer substrate. Do not adopt it if you need a single static binary with no cluster concepts, or if you expect the README alone to carry you through operations. Before committing, run the local cloud from the Quick Start, then read the Spore Drive deployment page and confirm which of the five services you actually need.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. README
4. Releases
5. taubyte/tau on GitHub