Production Blueprints

This page summarizes sane production approaches instead of raw feature lists.

Use these blueprints when you are deciding which topology to standardize on. They are intentionally opinionated: the goal is to reduce moving parts, not expose every possible transport at once.

Blueprint 1: Bedrock-only server

Use:

  • VoiceCraft.Server
  • McHttp
  • VoiceCraft.Addon.Core.McHttp

Why:

  • cleanest stable Bedrock deployment
  • easiest to monitor
  • easiest to explain to server staff

Recommended shape:

BDS addon -> McHttp -> VoiceCraft.Server
players -> VoiceCraft UDP endpoint

Keep McWss and McTcp disabled unless you have a specific reason to run them.

Blueprint 2: Local community / SMP with Geyser

Use:

  • VoiceCraft.Server
  • McTcp
  • GeyserVoice direct Paper mode

Optional:

  • let GeyserVoice manage the VoiceCraft runtime if you prefer a single Java-side install flow

Recommended shape:

Paper/Folia + GeyserVoice -> McTcp -> VoiceCraft.Server
players -> VoiceCraft UDP endpoint

This is a good fit when one Java-side server is the main authority for player position.

Blueprint 3: Large Java network

Use:

  • external VoiceCraft.Server
  • McTcp
  • GeyserVoice on proxy
  • GeyserVoice on backend nodes

Why:

  • central control
  • cleaner scaling
  • easier restarts without touching every backend

Recommended shape:

backend Paper nodes -> proxy relay -> proxy GeyserVoice -> McTcp -> VoiceCraft.Server
players -> VoiceCraft UDP endpoint

Keep the proxy as the only VoiceCraft connection owner. Backend nodes should produce snapshots, not compete for the main McTcp connection.

Blueprint 4: Builder / test environment

Use:

  • McWss
  • Core.McWss
  • a local VoiceCraft instance

Why:

  • fast local loop
  • good for testing addon automation

Recommended shape:

local Bedrock world -> McWss -> local VoiceCraft.Server
local client -> local VoiceCraft UDP endpoint

Do not treat this as the default production design for a public Bedrock server. Move to McHttp when the world becomes long-running or shared.

Choosing a blueprint

NeedChoose
Stable Bedrock productionBlueprint 1
One Java/Geyser serverBlueprint 2
Velocity/Bungee networkBlueprint 3
Local testing or addon developmentBlueprint 4

Operational recommendations

  • store VoiceCraft logs separately from game logs when possible
  • rotate or archive configs before large upgrades
  • keep transport tokens secret
  • test bind flow after every topology change
  • expose only the transport required by the chosen blueprint
  • keep a rollback copy of ServerProperties.json before changing ports or tokens
  • document which service owns the VoiceCraft process in your environment