Geyser 2.12.0

In the AWS Marketplace listing, choose Continue to Subscribe, then Continue to Configuration. Pick Geyser 2.12.0 on Ubuntu 24.04 as the software version and select your Region. Then choose Launch through EC2.

Choose m5.large, your key pair and a security group as described above. Geyser itself uses about 0.6 GB of memory, so size up if you also run your Java server on this instance.

To launch with the AWS CLI instead, replace the values in angle brackets:

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --associate-public-ip-address \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=geyser}]'

Create the security group rules with the AWS CLI:

aws ec2 authorize-security-group-ingress --group-id <your-security-group> \
  --ip-permissions 'IpProtocol=tcp,FromPort=19132,ToPort=19132,IpRanges=[{CidrIp=0.0.0.0/0}]' \
  'IpProtocol=udp,FromPort=19132,ToPort=19132,IpRanges=[{CidrIp=0.0.0.0/0}]' \
  'IpProtocol=tcp,FromPort=22,ToPort=22,IpRanges=[{CidrIp=<your-mgmt-cidr>}]'

Connect over SSH as the ubuntu user, which is the SSH user for Geyser 2.12.0 on Ubuntu 24.04:

ssh -i <your-key.pem> ubuntu@<public-ip>

The login message shows the address that players connect to and the commands used in the steps below.

A few seconds after boot, Geyser and its first-boot unit are active:

systemctl is-active geyser geyser-firstboot

active active

First boot records this instance's addresses (read with IMDSv2) in a note for you. The note holds connection details only, never a secret:

sudo cat /root/geyser-instance-info.txt

# Geyser - instance information (written by geyser-firstboot.service).
# Geyser has no administrator login: this note holds connection details only, never a secret. GEYSER_PUBLIC_IP=203.0.113.10 GEYSER_PRIVATE_IP=172.31.83.103 GEYSER_BEDROCK_PORT=19132 (TCP signaling + UDP NetherNet) GEYSER_CONFIG=/var/lib/geyser/config.yml
# Point Geyser at your Java Edition server: edit the java: section of the config, then
#
sudo systemctl restart geyser

Your addresses will differ. Bedrock players enter GEYSER_PUBLIC_IP with port 19132.

If the instance has no public IPv4 address, the note says none and Geyser offers players its private address. That address works only inside your VPC or VPN.

The image ships a self-test. It makes the same signaling request that every current Bedrock client makes before it joins (GET /v1/join on TCP 19132) and checks Geyser's reply:

geyser-selftest

OK NetherNet signaling: name="Geyser" protocol=2193 version=26.52 players=0/100 onlineAuth=true

A pass proves that the Java runtime started, the configuration parsed, NetherNet is on, signaling answers and online authentication is enforced. It does not need your Java server yet.

The same request works from your own computer against the public address, which also proves the security group:

curl -s http://<public-ip>:19132/v1/join

It returns a short JSON record with "name":"Geyser", the protocol, the Bedrock version and "onlineAuth":true.

NetherNet is set in the bedrock section of the configuration. First boot fills in the address that players are sent to:

sudo grep -n -E '^ transport:|^ advertise-addresses:|^ - ' /var/lib/geyser/config.yml

31: transport: nethernet 50: advertise-addresses: 51: - '203.0.113.10' 75: advertise-addresses: []

Line 50 is the built-in signaling list, which holds your public address. Line 75 belongs to the external signaling service, which this image does not use.

Geyser itself wrote the shipped config.yml during the image build, and it keeps Geyser's defaults apart from NetherNet. Its java section points at 127.0.0.1 port 25565, which works only if your Java server runs on this same instance:

sudo grep -n -A10 '^java:' /var/lib/geyser/config.yml

84:java: 85-
# The IP address of the Java Edition server. 86- address: 127.0.0.1 87- 88-
# The port of the Java Edition server. 89- port: 25565 90- 91-
# What type of authentication Bedrock players will be checked against when logging into the Java server. 92-
# Can be "floodgate" (see https://wiki.geysermc.org/floodgate/), "online", or "offline". 93- auth-type: online 94-

Edit the file with sudo nano /var/lib/geyser/config.yml:

• address and port: your Java server's address (an IP or DNS name reachable from this instance) and port. If the Java server runs on this instance, keep 127.0.0.1.
• auth-type: keep online when your Java server runs in online mode, which is the normal case. Players then sign in with their Microsoft accounts. Use floodgate only if you install the Floodgate plugin on your Java server. In that case, copy that server's key.pem to /var/lib/geyser/key.pem (owner geyser, mode 0640) and treat it as a secret. Avoid offline, because then anyone could join under any name.

Restart Geyser and wait for signaling:

sudo systemctl restart geyser for i in $(seq 1 30); do geyser-selftest >/dev/null 2>&1 && break; sleep 2; done; geyser-selftest

OK NetherNet signaling: name="Geyser" protocol=2193 version=26.52 players=0/100 onlineAuth=true

When the Java server is reachable, the server list entry shows your Java server's MOTD and player count (passthrough-motd). To check reachability from this instance, run nc -zv YOUR_JAVA_HOST 25565, replacing the host and port with your own.

In Minecraft (Bedrock Edition), open Play, then Servers, then Add Server. Enter a name, enter the instance's public address as Server Address and 19132 as Port, then save and join.

Consoles that cannot add servers directly need a DNS or "server list" workaround. See the Geyser documentation.

The trust prompt. Built-in signaling uses plain HTTP, which is Geyser's default. The first time a player joins by IP address, Minecraft shows a "trust on first use" prompt. After the player accepts it, the prompt does not appear again for this server. The gameplay connection itself is encrypted (WebRTC with DTLS). To remove the prompt, serve signaling over HTTPS with a certificate for a domain name (Step 8).

Bedrock client versions. Each Geyser release accepts the Bedrock versions it was built for. Geyser 2.12.0 build 1265 accepts Bedrock 26.52 (protocol 2193), as geyser-selftest shows.

Bedrock clients update automatically. When a newer Bedrock release is out, the Geyser log says so with a line starting There's a new Geyser update available to support Bedrock version:

sudo journalctl -u geyser --no-pager -o cat | sed -E 's/\x1b\[[0-9;]*m//g' | grep -E 'Loading Geyser version|Built-in signaling started|new Geyser update|NetherNet support' | tail -3

[00:28:59 INFO] Built-in signaling started on http://0.0.0.0:19132 [00:29:16 INFO] Loading Geyser version 2.12.0-b1265 (git-master-02dbfac) [00:29:23 INFO] Built-in signaling started on http://0.0.0.0:19132

If your players run a newer Bedrock version than this build accepts, upgrade Geyser as described in Step 10.

Only SSH (TCP 22) and Geyser on 19132 listen on the network. TCP 19132 is NetherNet signaling. Geyser opens UDP 19132 for each player's WebRTC connection as the player joins. The DHCP client on port 68 is the instance's own network setup:

sudo ss -H -tulnp | grep -v -E '127\.0\.0\.5[34]|\[::1\]|127\.0\.0\.1:323' | awk '{print $1, $5, $7}' | sed -E 's/,pid=[0-9]+,fd=[0-9]+//g'

udp 172.31.83.103%ens5:68 users:(("systemd-network")) tcp 0.0.0.0:22 users:(("sshd"),("systemd")) tcp [::]:22 users:(("sshd"),("systemd")) tcp *:19132 users:(("java"))

Geyser runs as the unprivileged geyser account in a sandboxed unit. The unit denies it access to the instance metadata addresses:

systemctl show geyser -p User -p NoNewPrivileges -p ProtectSystem -p PrivateTmp -p IPAddressDeny

IPAddressDeny=169.254.169.254/32 fd00:ec2::254/128 168.63.129.16/32 User=geyser PrivateTmp=yes ProtectSystem=strict NoNewPrivileges=yes

sudo systemd-analyze security geyser.service --no-pager | tail -1

→ Overall exposure level for geyser.service: 1.5 OK 🙂

The deny list holds only the metadata addresses, so Geyser still reaches your Java server, Microsoft sign-in and GeyserMC. The rule lives in /etc/systemd/system/geyser.service.d/50-sac-imds-deny.conf. Keep it.

The NetherNet identity key was created on this instance, and only the geyser account can read it:

sudo ls -l /var/lib/geyser/nethernet/

total 4 -rw------- 1 geyser geyser 288 Oct 20 00:27 identity.pem

Signaling takes the player's address from the connection. It ignores X-Forwarded-For unless you list a reverse proxy in advanced.bedrock.signaling-trusted-proxies, which is empty in this image.

To remove the trust prompt, give the server a DNS name, for example a Route 53 record pointing at an Elastic IP. Get a certificate for that name from a public certificate authority, then point built-in signaling at it in /var/lib/geyser/config.yml:

• bedrock.signaling.builtin.https.certificate: the path to the certificate chain (PEM), for example /var/lib/geyser/tls/fullchain.pem.
• bedrock.signaling.builtin.https.private-key: the path to its private key. Keep both files owned by geyser with mode 0600.
• bedrock.signaling.builtin.advertise-addresses: you can leave the IP address here. Players then add the server by its DNS name.

Restart Geyser. Signaling then serves HTTPS on TCP 19132 and refuses plain HTTP, so geyser-selftest, which speaks HTTP, reports a failure. Check with curl -s https://<your-domain>:19132/v1/join instead.

GeyserMC's HTTPS guide covers the options in detail, including a reverse proxy in front of the signaling port.

All settings live in /var/lib/geyser/config.yml, and each one is documented by a comment above it. Restart Geyser after a change (sudo systemctl restart geyser). The settings you are most likely to change, with the image default in parentheses:

• bedrock.port (19132): signaling (TCP) and NetherNet gameplay (UDP). Change the security group along with it.
• bedrock.transport (nethernet): how players connect. The value both also accepts the old RakNet method, but then needs a separate webrtc-port (another UDP port).
• bedrock.signaling.builtin.advertise-addresses (this instance's public IPv4): the address that players are sent to. First boot sets it. See Step 11.
• java.address, java.port (127.0.0.1, 25565): your Java Edition server (Step 5).
• java.auth-type (online): Microsoft account sign-in. See Step 5 before changing it.
• motd.primary-motd, motd.passthrough-motd (Geyser, true): the server list text. Passthrough shows your Java server's own MOTD.
• log-player-ip-addresses (true): player addresses in Geyser's log. Set it to false if you do not want them recorded.
• enable-metrics (true): anonymous usage statistics to bStats, which is Geyser's default. Set it to false to switch them off. Each instance gets its own random metrics-uuid at first boot.
• advanced.bedrock.use-haproxy-protocol (false): keep false unless Geyser sits behind a proxy that sends the PROXY protocol, or players could fake their address.

Geyser's own logs are in the systemd journal (sudo journalctl -u geyser) and in /var/lib/geyser/logs/.

Geyser is a single jar, and your config.yml stays as it is. Pick the release and build from GeyserMC's download page, and replace <version> and <build> below. The commands check the jar against the sha256 that GeyserMC publishes before installing it:

V=<version>; B=<build> API="https://download.geysermc.org/v2/projects/geyser/versions/${V}/builds/${B}" SUM="$(curl -fsSL "${API}" | python3 -c 'import json,sys; print(json.load(sys.stdin)["downloads"]["standalone"]["sha256"])')" curl -fsSL -o /tmp/Geyser-Standalone.jar "${API}/downloads/standalone" echo "${SUM} /tmp/Geyser-Standalone.jar" | sha256sum -c - \
  && sudo install -o root -g root -m 0644 /tmp/Geyser-Standalone.jar /opt/geyser/Geyser-Standalone.jar \
  && sudo systemctl restart geyser rm -f /tmp/Geyser-Standalone.jar

Then check the new version with the journalctl command in Step 6, and run geyser-selftest.

The image lays out its components as follows:

• Geyser Standalone 2.12.0 build 1265: /opt/geyser/Geyser-Standalone.jar (root owned)
• OpenJDK 21 (Ubuntu package, with security updates through unattended upgrades): /usr/lib/jvm
• Configuration and state: /var/lib/geyser/ (config.yml, permissions.yml, nethernet/, packs, extensions, logs, cache)
• JVM options -Xms256m -Xmx1024m: /etc/default/geyser
• Self-test: /usr/local/sbin/geyser-selftest
• Advertised address helper: /usr/local/sbin/geyser-set-address
• First boot: geyser-firstboot.service, with a note in /root/geyser-instance-info.txt
• Licence texts: /usr/share/doc/geyser/

If the instance's public address changes, for example after a stop and start without an Elastic IP, run first boot again. It updates the advertised address and the note. Then restart Geyser:

sudo rm -f /var/lib/sac/data/geyser-firstboot.done
sudo systemctl restart geyser-firstboot
sudo grep GEYSER_PUBLIC_IP /root/geyser-instance-info.txt
sudo systemctl restart geyser

To advertise a different address yourself, for example an Elastic IP that you attach later, run sudo geyser-set-address <address> and then sudo systemctl restart geyser.

• Allow TCP 22 only from your own networks. Only TCP and UDP 19132 need to be open to players.
• Keep auth-type: online, or use Floodgate with its key kept secret. Offline mode lets anyone impersonate any player.
• Keep /var/lib/geyser/nethernet/identity.pem private. If you copy it to another server, both servers share one identity.
• Use HTTPS for signaling when you have a domain name (Step 8).
• Protect your Java server too. If it runs elsewhere, allow its Java port only from this instance.
• Upgrade Geyser when Bedrock updates (Step 10). Unattended upgrades keep Ubuntu and OpenJDK patched.