# Spacewave: a self-hosted, local-first workspace that runs in the browser > Spacewave is a Go, TypeScript, React and WebAssembly stack for local-first apps that run in the browser with no server, sync peer-to-peer, and stay encrypted. This review covers what the repository documents, how to run it from source, and where it stops being the right tool. **s4wave/spacewave** — self-host directly in the web browser, no servers required. local-first - Repository: https://github.com/s4wave/spacewave - Website: https://spacewave.app - Stars: 591 · Forks: 10 - Language: Go - License: Apache-2.0 - Published: 2026-08-04 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/s4wave-spacewave ## What Spacewave solves, and for whom The README frames the problem as architectural rather than feature-level. Traditional web apps keep user data and processing on servers, and developers write API calls to reach it; server-side rendering, in the project's words, has increased dependence on servers and the cloud. Spacewave's answer is to move the application logic into the browser: WebWorkers and SharedWorkers on the web, native processes on desktop, with a storage abstraction so the same app can allocate a SQL database backed by Redis, BadgerDB or IndexedDB without a code change. The audience is narrower than the marketing line suggests. The first Getting Started branch is for people who simply want to use or self-host the app, and the README points them at spacewave.app, where it opens in a browser with no account. The second branch is for people who want to modify Spacewave or build plugins, and that path runs through the repository. The third is for developers building their own app on the Spacewave Stack, which the README directs to the bldr directory. If you are none of those three, the project is not aimed at you. The unit of work is the Space: shared encrypted state for files, notes, apps, layouts, devices and workflows. Spaces are multiplayer, so you invite people into one and work in it live. Storage placement is a user decision: your machines, the browser, your own server, or a cloud you pick. A paid account adds managed cloud storage and relay at $8/month for 100 GB, and the README states the app works without one. ## How the Bifrost, Hydra and GoScript layers fit together The architecture section names the components and their jobs. Bifrost is the network layer, described as peer-to-peer communication over any transport, with encrypted transport protocols and stream multiplexing, supporting WebRTC and WebSocket in the browser. Hydra is the data layer: SQL, key/value and graph structures, with pluggable backends including BadgerDB, Redis and S3, and IndexedDB in the browser. Bldr is the build system and development environment, using esbuild and vite for bundling, and handling cross-platform build and release. GoScript compiles Go module packages into readable TypeScript modules, so Go algorithms, data structures and runtime code can be shared without a second implementation; the README says it powers Bldr's Go compiler mode for web plugins and browser builds. On top of those sit Forge (a distributed job scheduler for CI/CD and workflow orchestration), Auth (password and PEM authentication primitives, plus shared building blocks for provider and session flows) and Identity (identity records and domain-backed configuration). SkiffOS, linked from the plugin list, is the Linux device layer, supporting 40+ device types and cross-compiling to any architecture. The data flow that matters for adoption is the one the README states explicitly: app logic executes in workers, storage is reached through an abstraction, and network traffic goes over Bifrost regardless of transport. That is what makes an offline-first, multiplayer app possible without a server in the middle. It is also why the project's surface area is large: a Go module, a TypeScript monorepo, generated protobufs, and a Python resource package all live in the same tree. ## Installing Spacewave from source and running the web app The README's Getting Started section splits usage from development. For use or self-hosting it points to https://spacewave.app, which opens the app in a browser with no account and no setup. Everything below is the from-source path, which the README documents under Running from source. Dependencies come first. The README gives a single command, and the repository's package.json confirms bun as the package manager and the script runner: ```bash # Install dependencies bun install ``` After that there are three start targets. The desktop app is the first, and the README labels it exactly that: ```bash # Start the desktop app bun run start:desktop ``` The web app has two variants, and the difference is how Go code reaches the browser. The default uses GoScript browser Go plugins; the second uses standard Go/WASM browser Go plugins: ```bash # Start the web app with GoScript browser Go plugins bun run start:web # Start the web app with standard Go/WASM browser Go plugins bun run start:web:wasm ``` If you change any .proto file, the README requires regenerating the protobufs before the change takes effect. Spacewave uses Protobuf for message encoding: ```bash # generate the protobufs bun run gen ``` The README also lists the verification commands: bun run test for everything, bun run test:go for Go only, bun run lint and bun run typecheck for static checks. Expect the first install to be heavy. The tree contains a Go module pinned to go 1.27.0 with a long replace block pointing at compatibility forks (badger, ristretto, pion/webrtc, wazero, go-mysql-server, go-git among them), a Python package requiring 3.11, and a monorepo with several import boundaries declared in package.json (auth, bldr, db, forge, identity, net). ## Where Spacewave is the wrong tool The README is candid about the browser's capabilities but silent on several operational questions that decide whether a team can run this. There is no documented rollback procedure, no migration guide for storage backends, and no compatibility statement for plugin APIs across releases. The CHANGELOG.org file exists in the tree, but the README does not describe a deprecation policy or a supported-version window. If your team needs a documented upgrade path before deploying, that documentation is not here. The version history supports reading the project as pre-1.0. The latest release listed is v0.57.0, and the package.json version field is 0.0.0-dev, which is the monorepo's own placeholder rather than a shipped artifact version. A minor-version cadence in the 0.5x range means interfaces can move between releases. The storage abstraction is the other edge. Being able to swap Redis for BadgerDB or IndexedDB without changing code is genuinely useful, but the README does not describe the consistency or durability guarantees of each backend, and it does not say what happens when two peers write the same structure while offline. For a multiplayer, offline-capable system that is the question that matters most, and the documentation does not answer it. Finally, the paid tier is part of the architecture, not an add-on. Managed cloud storage and relay at $8/month for 100 GB is how two devices that cannot reach each other directly get connected. The README says the app works without an account, and that is true for local use, but a team that wants reliable connectivity across restrictive networks is choosing between running its own relay or paying. ## Spacewave compared with Syncthing and with server-rendered web stacks The closest well-known comparison is Syncthing, and the difference is in what is being synced. Syncthing replicates files between devices and leaves the application on top of the filesystem; it has no notion of a shared application state, no plugin runtime, and no browser execution model. Spacewave's Hydra layer syncs data structures (SQL, key/value, graph) rather than files, and its Spaces carry apps, layouts, devices and workflows alongside the data. That is a larger and less mature claim. Syncthing's advantage is that its scope is small enough to be predictable, and it has years of operational history that Spacewave's README does not claim. The other comparison is with the server-rendered stack the README argues against. In a conventional Next.js-style application, the server owns the database and the client is a view layer; scaling multiplayer means scaling the server. Spacewave inverts that: the client owns the data, and collaboration happens over Bifrost between peers. The trade-off is that you inherit the browser's storage limits, the difficulty of debugging code running in a worker, and the need for a relay when peer-to-peer fails. The README's own analogy, that rendering a video game fully server-side would be too laggy, is a fair description of the latency argument, but it does not address the operational argument, which is that a server is a place where you can inspect state. Here, the state is on the user's machine. For developers who want the local-first model without adopting Spacewave wholesale, the relevant comparison is the underlying stack: Bldr as a build system, GoScript as a Go-to-TypeScript compiler, and Hydra as the storage layer are each usable on their own terms according to the repository layout, though the README presents them as components of Spacewave rather than standalone products. ## Licence, maintenance and the cost of upgrading Spacewave is licensed under Apache-2.0, and the LICENSE file sits at the repository root. Apache-2.0 permits commercial use and modification and includes an explicit patent grant, which matters for a project that ships a compiler (GoScript) and a device layer (SkiffOS). The repository's package.json lists Aperture Robotics LLC as the author with a support address, and the go.mod replace block redirects several upstream modules to aperture-prefixed forks. If you vendor this code, those replacements travel with it, and you should read the licence of each fork rather than assuming the root Apache-2.0 covers them. That is a reading task, not legal advice. On maintenance, the facts are the dates. The repository is not archived. The last push was on 2026-07-31, which is under two months before today, and the most recent release listed is v0.57.0 on the same date, with v0.56.1 on 2026-07-18 and v0.56.0 on 2026-07-11. That cadence shows work landing through July 2026, and the release numbering shows it is still pre-1.0. The upgrade cost follows from the stack rather than the cadence. A version bump can touch the Go module, the bun lockfile, generated protobufs and the Python resource package at once. The README's instruction to run bun run gen after any .proto change implies that generated code is checked in and must be regenerated in step with the source. Budget for that on every upgrade, and read CHANGELOG.org before you bump, since the README does not summarise what changed between releases. ## Conclusion Adopt Spacewave if you want a local-first workspace whose app logic runs in WebWorkers in the browser and as native processes on desktop, and you are willing to build from source with bun and Go 1.27. Do not adopt it if you need a documented rollback or migration path, a stable plugin API, or a managed service without the $8/month cloud. Verify first that the bun scripts in package.json (start:web, start:web:wasm, test:go) run against your toolchain, and read LICENSE for the Apache-2.0 terms before you ship a derived app. ## FAQ ### What is the Spacewave app? Spacewave is a self-hosted, local-first workspace that runs in the browser with no server and no account, and syncs peer-to-peer between your devices. As your work grows, the workspace becomes a Space: shared encrypted state for files, notes, apps, layouts, devices and workflows, which other people can be invited into. ### Is Spacewave free to use? The README states the app works without a paid account, and you can open it in a browser with no account or setup. A paid account adds managed cloud storage and relay at $8/month for 100 GB. ### How do I install Spacewave from source? The README's Running from source section starts with bun install, then offers bun run start:desktop, bun run start:web for GoScript browser Go plugins, and bun run start:web:wasm for standard Go/WASM browser Go plugins. If you change a .proto file, run bun run gen to regenerate the protobufs. ### What storage backends does Spacewave support? Hydra, the data layer, supports SQL, key/value and graph structures with pluggable backends including BadgerDB, Redis and S3, and IndexedDB in the browser. The README states an app can allocate a SQL database and store it in Redis, BadgerDB or IndexedDB without changing a line of code when switching backends. ### What transports does Spacewave sync over? Bifrost handles networking over any transport, supporting WebRTC and WebSocket in the web browser, with encrypted transport protocols and stream multiplexing. The README lists WebRTC, WebSocket, LAN and relay as the networks your devices can reach. ### Is Spacewave still in development? The repository is not archived and the last push was on 2026-07-31. The most recent release listed is v0.57.0, so the project is still pre-1.0 and the README does not document a deprecation policy or a supported-version window. ## Sources - [Official documentation](https://spacewave.app) - [Official README](https://github.com/s4wave/spacewave#readme) - [Project repository](https://github.com/s4wave/spacewave) - [Release notes](https://github.com/s4wave/spacewave/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/s4wave-spacewave