Skip to content

feat(grounds-velocity): mount the floodgate key for a bedrock proxy - #161

Merged
hbrombeer merged 1 commit into
mainfrom
feat/velocity-floodgate-key
Aug 13, 2026
Merged

feat(grounds-velocity): mount the floodgate key for a bedrock proxy#161
hbrombeer merged 1 commit into
mainfrom
feat/velocity-floodgate-key

Conversation

@hbrombeer

Copy link
Copy Markdown
Member

Completes the proxy half of Bedrock support. Geyser terminates the Bedrock session and connects to a Velocity proxy as a Java client; Floodgate on that proxy is what actually admits the player.

Why the key is mounted somewhere neutral

Floodgate reads its key from its own plugin data directory — and also creates a config.yml there on first start. Mounting the Secret straight onto plugins/floodgate makes that directory read-only and the plugin fails to initialise.

That is the same trap Geyser has with its own config (#160), and it was only visible by running the image. So the Secret lands at /var/run/secrets/floodgate and the velocity image's start.sh copies it in, leaving the directory writable. Requires groundsgg/containers#223.

Why it is referenced, never generated

Geyser signs the Bedrock player's data with this key and Floodgate verifies the signature. Both sides must see byte-identical keys — a chart that generated its own would produce a key the Geyser side does not have, and every Bedrock login would fail its signature check. Same reason velocity-forwarding-secret is provisioned out of band.

Inert when off

Default enabled: false renders no env, no volume and no mount, so nothing changes for any existing release.

Enabling it also means setting VELOCITY_FORCE_KEY_AUTHENTICATION=false, because Bedrock players carry no Mojang profile key and are kicked at login while it is enforced. That is not something to do on a proxy serving Java players — which is why Bedrock gets its own release (velocity-bedrock in groundsgg/deploy#135) rather than a flag on the shared ones.

Verified

  • helm lint clean
  • rendered with floodgateKey.enabled=falsezero floodgate references
  • rendered with it enabled → FLOODGATE_KEY_FILE, the volume and the mount all present
  • kubeconform -summary -strict on both renders: 2/2 valid each

Floodgate is what lets an online-mode proxy accept a player who has an Xbox
Live account and no Mojang one: Geyser signs the Bedrock player's data with a
shared key and Floodgate verifies the signature. Both sides have to see
byte-identical keys, so the Secret is referenced and never generated — the
same reason velocity-forwarding-secret is provisioned out of band.

Mounted somewhere neutral rather than onto plugins/floodgate. Floodgate also
creates a config.yml in its data directory on first start, and a read-only
mount there stops the plugin initialising — the same trap Geyser has with
its own config, found by running the image rather than rendering it. The
velocity image's start.sh copies the key in from FLOODGATE_KEY_FILE.

Off by default and inert when off: no env, no volume, no mount, so nothing
changes for a proxy that has no Bedrock players. Enabling it also means
setting VELOCITY_FORCE_KEY_AUTHENTICATION=false, which is not something to
do on a proxy serving Java players — hence a separate release for Bedrock
rather than a flag on the shared ones.
@hbrombeer
hbrombeer merged commit a8c8da7 into main Aug 13, 2026
4 checks passed
@hbrombeer
hbrombeer deleted the feat/velocity-floodgate-key branch August 13, 2026 17:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant