Home

GoCraft Wiki

A native-Go Minecraft server built from scratch around an edition-agnostic core.

Java Edition 1.21.4 · Bedrock Edition 1.26.45 · Cross-play · No JVM

⚠️ GoCraft is early experimental software. It is not production-ready and should not be exposed as a public server. Expect breaking changes during development.

---

What is GoCraft?

GoCraft is a native Go implementation of a Minecraft server written from scratch. It is not a Paper fork, does not use the JVM, and is not a drop-in replacement for any existing server software.

Both Java and Bedrock clients connect to the same server, share the same world and entities, and see each other in real time — with no external proxy required.

Unlike proxy translators such as Geyser, GoCraft is not a protocol converter. Both the Java and Bedrock adapters read from one canonical game core and each produce their own native wire format. See Architecture.

---

Why GoCraft? ("Pumpkin already exists and it's better")

It's a fair question, and the honest answer is: GoCraft isn't trying to be a faster Java server than Pumpkin — it's solving a different problem.

Pumpkin (Rust) and most alternative server rewrites are excellent, but they target one edition — a native Java server. Bedrock support in that world almost always means bolting on a proxy/translator (Geyser-style) that converts Java packets to Bedrock at the edge.

GoCraft's defining goal is different:

One canonical, edition-neutral simulation that serves both Java and Bedrock natively — no proxy, no translation layer.

Concretely, that means:

• True shared-core cross-play. The world, entities, players, combat, and time live in core/, which knows nothing about Java or Bedrock. Each edition has its own adapter that reads that same state and speaks its own native wire format. A Java and a Bedrock player aren't two worlds bridged together — they're the same world. See Architecture.
• No proxy in the middle. Nothing re-encodes Java packets for Bedrock. Both protocols evolve independently, avoiding the coupling and edge-cases translators inherit.
• Go, deliberately. A single static binary, no JVM, simple concurrency, fast builds, and an approachable codebase for contributors who want to hack on a server without a huge toolchain.
• A clean architectural invariant. The build fails if core/ ever imports an edition adapter (core/world/arch_test.go), which keeps the edition-neutral core honest as the project grows.

And on the performance worry specifically: GoCraft's footprint is in the same ballpark as Pumpkin's. Both are native, non-JVM servers, so the difference in memory and CPU use is small — not the order-of-magnitude gap people sometimes assume when comparing to a Java server. You are not trading away meaningful performance to get cross-play. On top of that, GoCraft gives you something Pumpkin doesn't: native, first-class Bedrock — the real Bedrock protocol served directly from the shared core, not a translated or proxied approximation.

None of this makes Pumpkin "wrong" — GoCraft actually studies Pumpkin's data and AI goal models as a reference. If you want the fastest possible Java-only server, projects like Pumpkin are a great choice. If you want Java and Bedrock players in one shared, native world from a single Go binary, that's the niche GoCraft is built for.

And to be clear: GoCraft is early experimental software, not a finished product. It's a from-scratch exploration of that cross-edition-core idea, not a drop-in replacement for a mature server.

Why Go is a great fit for a Minecraft server

The original Minecraft server runs on the JVM, which is powerful but heavy: it reserves a large managed heap, adds significant baseline RAM overhead per instance, and pays for a big runtime and JIT warm-up before it reaches full speed. On small VPSes and multi-instance hosts, that memory cost is often the real bottleneck — not CPU.

Go changes that equation:

• Low, predictable memory footprint. No JVM heap to pre-size, no separate runtime process — a GoCraft instance starts lean and stays lean, which matters when you're running on modest hardware or packing many servers onto one box. Less RAM per instance means more instances (or more players) on the same machine.
• No JVM to install or tune. GoCraft compiles to a single static binary. No -Xmx/-Xms flags, no Aikar's GC tuning, no JDK dependency — copy the binary and run it.
• Fast startup. Native code with no JIT warm-up means the server is at full performance from the first tick, so restarts and cold boots are quick.
• Concurrency built for many connections. Go's goroutines are extremely cheap compared to OS threads, and the scheduler is designed for exactly the "thousands of lightweight concurrent tasks" shape a network game server has — player connections, chunk streaming, entity ticking.
• A low-pause garbage collector. Go's GC is tuned for low latency rather than raw throughput, which suits a tick-based server where long stop-the-world pauses would show up as lag spikes.
• Simple deployment & ops. One binary, cross-compiles for Linux/Windows/ARM, tiny container images, and easy to drop into a Pterodactyl egg or a bare VPS.

The trade-off is honest: a mature JVM server has years of optimization and a huge plugin ecosystem behind it. GoCraft is betting that a lean, native, single-binary server with a genuine cross-edition core is worth building — especially for people who want to run Minecraft without the JVM's memory tax.

---

Compatibility

Client	Status
Minecraft: Java Edition 1.21.4 (protocol 769)	Active development target
Minecraft: Bedrock Edition 1.26.45 (protocol 2169)	Beta — full cross-play support
Other versions	Not supported

---

Highlights

• No JVM — pure Go, single binary, low memory footprint
• Java + Bedrock cross-play — both editions share the same canonical world and entity simulation
• Custom items — define items in YAML; GoCraft auto-generates Java resource packs and Bedrock behavior packs at startup
• Permission editor — browser-based group editor via bytebin relay, no inbound port needed
• MiniMessage — gradients, hex colors, and glyphs in chat, prefixes, and item names
• Resource packs — push .mcpack, .zip, and .mcaddon files to Bedrock clients; serve Java packs automatically
• Native Go plugins — isolated processes with owned events, commands, scheduling, and configuration
• Persistent world — Anvil region files, autosaves, atomic writes, memory-mode option
• Data-driven — block states, item IDs, entity types, biomes, and packet IDs loaded from versioned JSON at startup

---

Documentation map

Page	What it covers
Getting Started	Clone, build, run, and connect a client
Configuration	Full server.yml reference and environment overrides
Gameplay and Features	Every gameplay system: world gen, blocks, redstone, mobs, combat
Commands	Every built-in command and its permission node
Permissions	Group-based permissions and the browser editor
Chat and Formatting	MiniMessage, chat format, and glyphs
World Management	Storage, whitelist, bans, ClearLag, performance
Bedrock and Cross-Play	Bedrock setup, shared features, packs, limitations
Custom Items	Cross-edition custom item system
Native Go Plugins	Plugin lifecycle, events, commands, packaging
Architecture	Core design, adapter pattern, block identity
Project Structure	Directory-by-directory tour of the codebase
Contributing	Rules for keeping the core edition-neutral
FAQ	Common questions

---

Development status

Milestone	Status
1–3 — Handshake, login, configuration	Complete
4–5 — World, chunk streaming, movement	Complete
6–7 — Multiplayer sync, chat	Complete
8–10 — Block interaction, persistence, inventory	Complete
11–13 — Entity system, commands, data-driven registries	Complete
14 — Bedrock adapter	Beta
Custom items (Java + Bedrock)	In progress
15 — Go plugin API	Experimental

---

Community & license

• Discord: https://discord.gg/Her3JEWWdj
• License: GNU General Public License v3.0 (GPL-3.0)
• Copyright © 2026 Oreo Studios — oreostudios.fr

Minecraft is a trademark of Microsoft. GoCraft is an independent project and is not affiliated with or endorsed by Mojang Studios or Microsoft.