# Voxelize: a Rust voxel server with a TypeScript and Three.js client

> Voxelize is a full stack voxel engine split across a Rust authoritative server, a TypeScript browser client and a shared protobuf protocol. It suits teams that want to own the server and the world generation, and it asks for a Rust, pnpm, wasm-pack and protoc toolchain first.

**voxelize/voxelize** — :mushroom: Full stack voxel engine

- Repository: https://github.com/voxelize/voxelize
- Website: https://shaoruu.io
- Stars: 691 · Forks: 113
- Language: TypeScript
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/voxelize-voxelize

## A full stack engine split across two languages

Voxelize describes itself as a full stack voxel engine, and the repository layout backs that description rather than the marketing. The server is written in Rust, the client is written in TypeScript on top of Three.js, and the two halves talk over WebSocket using protobuf messages that both sides share.

The audience is teams building a multiplayer voxel world, usually a building or social server rather than a single player sandbox. The README lists what the engine is meant to remove from that job: you can register blocks of any shape, size and material, including block entities that carry custom metadata, you can define entities that roam and interact with blocks and players, you get realtime multiplayer with an authoritative server plus entity, chat and event synchronization out of the box, and you define your own world generation for infinitely large worlds.

The pitch in the README is that this runs in a modern browser with no installs and no plugins. That framing matters for how you judge the project: nothing here is a Minecraft style world format with a plugin ecosystem. World rules are code you write and ship.

## The server is authoritative and ECS driven

The mechanism on the server side is an entity component system. According to the README, the Rust crate named voxelize runs ECS driven worlds, and chunk generation, physics, entities and events all live server side. The Cargo workspace makes the pieces explicit: the root package is the voxelize library, with a path pointing at server/lib.rs, and it pulls in voxelize-core, voxelize-mesher and a physics stack built on rapier3d, plus specs for the ECS layer itself.

Two examples are registered directly in Cargo.toml, a demo server and a viewer backend, and each lives under examples/. So the shape of a server is a Rust binary that embeds the library, registers systems, and then serves the client.

Because the server owns physics, entities and events, a client is a renderer and an input source rather than a second source of truth. That is the single most important architectural decision in the project, and it is also the one that dictates your deployment: you need a long running server process, not a static page.

The workspace itself is small and explicit, with the mesher, the core data layer and a generation crate as members, and the WebAssembly mesher deliberately kept outside the workspace so it can build through wasm-pack with its own profiles.

## Getting the demo running needs Rust, pnpm and protoc

There is no prebuilt binary or hosted playground in the README, so the first real use is building from source. The prerequisites are listed explicitly: Rust, Node.js, pnpm, cargo-watch, wasm-pack and protoc. That is a heavy list, and protoc in particular is easy to forget until the protocol generation step fails.

The Quick Start is five commands:

```bash
git clone https://github.com/voxelize/voxelize.git
cd voxelize

pnpm install   # install dependencies
pnpm proto     # generate protocol buffers
pnpm build     # build WASM mesher + all packages
pnpm demo      # run the demo server and client
```

After that, the README says to open http://localhost:3000.

The script definitions in package.json show what the demo actually starts. The demo script runs the TypeScript client and the Rust server in parallel, and the Rust side runs under cargo watch with the release-dev profile:

```json
    "demo": "npm-run-all --parallel \"demo:ts\" \"demo:rs\"",
    "demo:ts": "cd examples/client && pnpm demo",
    "demo:rs": "cross-env RUST_BACKTRACE=1 cargo watch -w examples/server -w server -x \"run --profile release-dev --example demo\"",
```

One instruction in the README is worth repeating because it decides your integration approach: the author strongly recommends using Voxelize as a submodule of the workspace you are building, rather than copying files into it.

## Meshing happens twice, in Rust and in WebAssembly

The mesher is where the two halves meet, and Voxelize handles it in an unusual way. The server side has voxelize-mesher, a native Rust crate that turns voxel data into geometry. The client side has voxelize-wasm-mesher, which the README describes as compiling the server's mesher to WebAssembly so that client side remeshing follows the same geometry rules as server side meshing.

That is the interesting engineering claim in the project, and it is the reason the build step involves wasm-pack and a standalone cargo workspace for the WASM crate. The tradeoff is build complexity: any change to meshing rules has to travel through the Rust crate, into WASM, and back into the npm build pipeline, and pnpm build is what stitches the packages together in the right order.

The protocol layer follows the same do not duplicate the rules idea. @voxelize/protocol holds the shared protobuf message definitions, and @voxelize/transport moves those messages over WebSocket. A file called messages.proto sits at the repository root, and pnpm proto regenerates the bindings from it.

On the client side, @voxelize/core is the engine itself, covering rendering, world sync, inputs and utilities on Three.js, with @voxelize/physics-engine providing voxel aware AABB physics and raycast handling.

## Headless agents and a Rust test surface for the browser client

Voxelize treats the browser client as something you can drive without a browser in front of it. The @voxelize/agent package is a headless puppeteer backed agent SDK for Voxelize worlds, and the README says it drives real browser clients headlessly for testing, measurement and bots. That is a different approach from testing game logic purely on the server, and it matters because in this engine the client holds rendering and input code that no Rust test touches.

The repository also carries a substantial Rust verification surface, visible in the script names rather than in prose:

```json
    "test": "vitest --run",
    "test:rust": "cargo test --test mesher_tests --test lights_tests && cargo test -p voxelize-gen",
    "bench": "cargo bench --bench mesher_bench --bench lights_bench",
    "check:boundary": "node scripts/engine-boundary/check.mjs",
```

Two details stand out. There are dedicated tests for the mesher and for lights, which are the two areas where a silent visual regression is hardest to spot. And there is an engine boundary check, a Node script under scripts/engine-boundary with its own test, which suggests the project enforces where code may live across the TypeScript and Rust sides.

The benches directory at the repository root mirrors this, with mesher and lights benchmarks and a generation benchmark, reported through criterion.

## Where Voxelize is the wrong tool

The README markets the absence of plugins as a feature, and for a team that wants to own its rules that is correct. It is also a limitation. If you expect a marketplace of ready made gameplay modes, or a way to have non programmers add features, Voxelize offers no path to that, because every behaviour is something you implement in Rust or TypeScript and redeploy.

The toolchain cost is the other boundary. Before you write a single world generator you need Rust, Node.js, pnpm, cargo-watch, wasm-pack and protoc on the machine, and the build produces both native Rust artifacts and a WebAssembly mesher. Teams that standardised on one language and one package manager will feel this twice, once in the build and again in the debugging story, since a browser side problem lands in the TypeScript client while a physics or chunk problem lands in the Rust server.

The alternative to adopting Voxelize is assembling the same pieces yourself: a Three.js renderer in the browser, a WebSocket layer of your own, a server that owns physics and entities, and a mesher that produces the same geometry on both sides. The difference in approach is ownership. Rolling your own gives you exactly the boundaries you want and no shared protocol to conform to, but it also means you write the ECS wiring, the protobuf definitions and the WASM meshing story from nothing. Voxelize bundles those decisions at version 3.0.0, and you inherit them.

## MIT licensed, no tagged releases, recently pushed

Licensing is straightforward. The package.json declares MIT and the Cargo package declares MIT as well, with the license file at the repository root. There is no copyleft obligation and no restriction in the sense that the code can be used in a commercial server; the practical obligations are the usual attribution ones, and this is not legal advice.

On maintenance, the repository is not archived and the last push was on 2026-10-19, so the code base is being worked on. What it does not have is tagged releases. The GitHub releases list is empty, and version 3.0.0 appears in the Cargo manifest for the root package, in the crate paths and in the client package, which means the version is coordinated across the Rust and TypeScript halves rather than published per package.

That combination, active work plus no release tags, is the main upgrade question for an adopter. Because the crates are path dependencies inside the workspace, you consume them from source, and the Cargo workspace members list shows how narrow the surface is:

```toml
members = [".", "crates/core", "crates/gen", "crates/mesher"]
exclude = ["crates/wasm-mesher"]
name = "voxelize"
version = "3.0.0"
```

Pinning to a commit rather than a release tag is the practical consequence, and the submodule arrangement the README recommends is what makes that pinning easy to manage.

## Conclusion

Adopt Voxelize if you want a persistent multiplayer voxel world where you control the server, the protocol and the world generation, and if your team can keep a Rust and TypeScript toolchain alive. Do not adopt it if you want a drop in editor with plugins, or if a Node only stack is a hard constraint. Verify first that your target browsers and hardware can carry the client and that the demo builds in your environment, since the Quick Start requires Rust, Node.js, pnpm, cargo-watch, wasm-pack and protoc before any code runs.

## FAQ

### How do I run the Voxelize demo locally?

Clone the repository, install the Rust, Node.js, pnpm, cargo-watch, wasm-pack and protoc prerequisites, then run pnpm install, pnpm proto, pnpm build and pnpm demo from the repository root. The demo starts the TypeScript client and the Rust server in parallel, and you open http://localhost:3000.

### What language is Voxelize written in and how do the client and server talk?

The server is written in Rust as an ECS driven authoritative world and the client is written in TypeScript on top of Three.js. They exchange protobuf messages defined in @voxelize/protocol, carried over WebSocket by @voxelize/transport.

### Can Voxelize be used as a dependency in an existing project?

The client, transport, protocol, physics and agent packages are published on npm under the @voxelize scope, and the server crate is published on crates.io as voxelize. The README recommends using Voxelize as a submodule of the workspace you are building rather than copying files in.

## Sources

- [Issues](https://github.com/voxelize/voxelize/issues)
- [License: MIT](https://github.com/voxelize/voxelize/blob/main/LICENSE)
- [Project website](https://shaoruu.io)
- [README](https://github.com/voxelize/voxelize/blob/main/README.md)
- [voxelize/voxelize on GitHub](https://github.com/voxelize/voxelize)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/voxelize-voxelize