Spacewave: A Browser-Native Local-First Workspace with Peer-to-Peer Sync
self-host directly in the web browser, no servers required. local-first
At a glance
- What is it?
- Spacewave is a self-hosted, encrypted workspace that runs entirely in the browser, using WebAssembly and peer-to-peer sync. It targets developers who want local-first apps without managing servers, but its complexity and evolving ecosystem require careful evaluation.
- Who is it for?
- Adopt Spacewave if you are a developer comfortable with a Go/TypeScript stack and want a local-first, encrypted workspace that runs in the browser, with the option to self-host or use paid cloud storage. Do not adopt it if you need a mature, production-ready platform with extensive documentation or if you require server-side processing for heavy workloads.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Spacewave Solves and Who It Is For
Spacewave addresses the problem of building and using web apps that depend on servers for data storage and processing. The README argues that traditional web apps, and especially server-side rendering, force users to rely on cloud infrastructure, which hurts offline usability and complicates self-hosting. Spacewave instead runs the entire application logic in the browser using WebAssembly, WebWorkers, and IndexedDB. It is for developers who want to create local-first, multiplayer, encrypted apps without operating a backend, and for users who want a private workspace that syncs between their own devices. The target audience is technical: the project is built with Go, TypeScript, React, and WebAssembly, and the README emphasizes that every app is local-first and encrypted by default.
How the Architecture Works: WebWorkers, WebAssembly, and Pluggable Storage
The core mechanism is running app logic in WebWorkers or SharedWorkers in the browser, and as native processes on desktop. This brings the Go ecosystem to the browser via WebAssembly. The README describes two key components: Bifrost handles network communication over any transport, including WebRTC and WebSocket, with encrypted stream multiplexing. Hydra provides data storage with peer-to-peer sync, supporting SQL, key-value, and graph databases, and pluggable backends like BadgerDB, Redis, S3, and IndexedDB. The abstraction layer lets an app allocate a SQL database and switch backends without changing code, as the README states. This design is ambitious: it aims to make browser apps fully self-sufficient, but the complexity of coordinating WebWorkers, WebRTC, and multiple storage backends is significant. The README does not detail how conflicts are resolved during sync, which is a critical gap for a peer-to-peer system.
Getting Started: Commands and Modes
The README gives clear commands for running from source. You need bun as the package manager. After cloning, run `bun install` to install dependencies. Then you can start the desktop app with `bun run start:desktop`, or the web app with either `bun run start:web` for GoScript browser Go plugins or `bun run start:web:wasm` for standard Go/WASM plugins. The test suite includes `bun run test`, `bun run test:go`, `bun run lint`, and `bun run typecheck`. Since Spacewave uses Protobuf for message encoding, you must regenerate protobufs after changing any `.proto` file with `bun run gen`. These commands are straightforward, but note that they assume a modern JavaScript toolchain and a Go environment for the WASM builds. The README does not specify minimum versions for bun or Go, which could be a stumbling block for new users.
The Component Ecosystem: Bifrost, Hydra, Bldr, and More
Spacewave is not a single app but a collection of components. Bifrost is the networking layer, Hydra is the data layer, and Bldr is a build system and development environment with hot reload using esbuild and vite. GoScript compiles Go to TypeScript, allowing Go algorithms to be reused in the browser without a second implementation. SkiffOS extends the ecosystem to Linux devices, supporting 40+ device types and cross-compilation. Forge provides CI/CD and workflow orchestration, and there are Auth and Identity modules for authentication and domain primitives. This modularity is powerful: you can pick components for your own projects. However, the README does not provide detailed API documentation or examples for each component, so the learning curve is steep. The components are listed as designed to be used together, but the README is truncated, and it is unclear how mature each component is or how they integrate in practice.
Limitations and Failure Modes
A genuine limitation is that Spacewave depends heavily on browser features like WebAssembly and WebWorkers, which may not be available or consistent across all browsers. The README does not mention browser compatibility requirements. Another failure mode is the peer-to-peer sync over arbitrary networks. The README lists WebRTC, WebSocket, LAN, and relay as supported, but it does not explain what happens when NAT traversal fails or when a device is offline for a long time. Conflict resolution is not described, which is a critical omission for a collaborative system. Additionally, the app runs entirely in the browser, meaning that for large datasets, performance could degrade because all processing happens client-side. The README claims the app works without a paid account, but the paid tier adds managed cloud storage and relay, which suggests that pure peer-to-peer may not be sufficient for all use cases, especially when devices cannot connect directly.
Alternatives and How They Differ
A real alternative is a traditional self-hosted solution like Nextcloud, which uses a central server for storage and sync. Nextcloud requires you to run and maintain a server, but it offers mature file sync, collaboration, and a large app ecosystem. The approach is fundamentally different: Nextcloud is server-centric, while Spacewave is client-centric with peer-to-peer sync. Another alternative is a local-first framework like Automerge or Yjs, which provide conflict-free data structures for collaborative apps. These libraries handle synchronization at the data level, but they do not provide a full workspace or plugin ecosystem. Spacewave aims to be a complete platform, but its components are less proven than these alternatives. The README does not compare itself to any specific competitor, but the architectural choice is clear: Spacewave bets on browser-native execution, while others rely on servers or embeddable CRDTs.
Maintenance, Licensing, and Upgrade Considerations
Spacewave is licensed under Apache-2.0, which permits commercial use and modification, but you should review the license terms for specific obligations. The project is actively maintained, with recent releases including v0.57.0 in July 2026. The version number suggests it is still pre-1.0, and breaking changes are likely. The README mentions a paid account for managed cloud storage and relay at $8/month for 100 GB, but the app works without one. For maintenance, you will need to keep up with bun, Go, and the various components. The protobuf generation step means that any upgrade that changes message formats will require running `bun run gen` and potentially updating your code. The plugin ecosystem is a key feature, but the README does not provide a plugin development guide beyond pointing to the Bldr directory. You should check the repository's issues and commit history to gauge stability, but the README does not offer migration guides or upgrade notes.
Editorial conclusion
Adopt Spacewave if you are a developer comfortable with a Go/TypeScript stack and want a local-first, encrypted workspace that runs in the browser, with the option to self-host or use paid cloud storage. Do not adopt it if you need a mature, production-ready platform with extensive documentation or if you require server-side processing for heavy workloads. Before committing, verify the current state of the plugin ecosystem, the stability of the peer-to-peer sync across different networks, and the completeness of the Bldr and GoScript toolchains for your specific use case. Check the repository's recent commits and issues to see if active development addresses your needs.
Community notes