Minecraft Server Power and Version Changes

After the first deployment, manage VM power with gcloud. Change the values written in code, such as the firewall, the machine specification, and the JAR, through a saved Terraform plan. Keeping the two paths apart stops the next plan from trying to undo an operator’s manual power action.

Prerequisites

At least one archive from part 06 must have passed the isolated load test.

Unless another path is given, run the commands below in ${HOME}/minecraft-one-root in Cloud Shell.

Server Power

Run

export MINECRAFT_INSTANCE="$(
  terraform output -raw minecraft_instance_name
)"
export MINECRAFT_ZONE="$(
  terraform output -raw minecraft_zone
)"

Check that no one is connected, then stop the VM.

Conditional run: when the server is not in use

gcloud compute instances stop "${MINECRAFT_INSTANCE}" \
  --zone="${MINECRAFT_ZONE}"

Once it reads TERMINATED, the VM’s CPU and memory runtime charges stop. Boot disk and static external IPv4 charges can remain. Keep watching the Cloud Storage cost as well.

Start it again when you want to use it.

Run

gcloud compute instances start "${MINECRAFT_INSTANCE}" \
  --zone="${MINECRAFT_ZONE}"

Minecraft still needs time after RUNNING. As in part 05, check systemd’s active and then Done (...)! in the log. If an error says there is no Spot capacity, do not repeat the start command at short intervals. Look at another machine type in the same zone first. Changing zone can replace the VM and the boot disk, so moving to another zone needs a separate migration plan that restores a verified backup onto a new server.

The Order to Follow for Any Change

Use the same order whenever you change a value that Terraform manages.

1. If the world has changed a lot since the backup verified in part 06, make a new backup.
2. Edit only one place: terraform.tfvars or an example script.
3. Create a named plan file and read it with terraform show.
4. Apply the saved plan when only the resources you expected change.
5. For a change that needs a reboot, stop and start the VM, then check all the way to Done (...)!.

Do not apply a plan that contains even one unexpected replace or destroy.

When the Administrator Public IP Changes

When a home line or a VPN exit address changes, the SSH firewall refuses the new address. This happens more often if you operate from Cloud Shell, whose public IP can change in a new session. When gcloud compute ssh times out, first compare the current public IP with admin_cidr.

Check

curl --fail --silent --show-error https://api4.ipify.org

If the output differs from admin_cidr in terraform.tfvars, change only admin_cidr to the new public IPv4 with /32.

Run

nano terraform.tfvars
terraform fmt
scripts/preflight.sh
terraform plan -out=admin-ip.tfplan
terraform show admin-ip.tfplan

The expected plan is a single source_ranges entry change on the SSH firewall rule. No VM reboot is needed.

Run

terraform apply admin-ip.tfplan

To roll back, enter the previous IP again and create a new plan. Do not widen the range to 0.0.0.0/0 because you are locked out.

When Changing the Machine Type

If memory runs short as the player count and world computation grow, change machine_type in terraform.tfvars.

machine_type = "e2-standard-4"

Changing only machine_type leaves the JVM -Xms and -Xmx values in scripts/startup.sh unchanged. To raise memory too, open scripts/startup.sh and edit both values on the ExecStart=/usr/bin/java -Xms2G -Xmx4G ... line. On e2-standard-4 (16 GiB), -Xms4G -Xmx8G is an example that leaves memory for the operating system and non-heap use; choose production values from heap and whole-VM measurements under load. The file is delivered through VM metadata, so its change appears in the plan and takes effect after the applied VM is rebooted.

After editing both the input and startup script, create the new plan.

Run

terraform plan -out=machine-type.tfplan
terraform show machine-type.tfplan

The expected plan changes machine_type in place and, if you edited the startup script, updates the metadata. Because of allow_stopping_for_update = true in compute.tf, the provider may stop the VM during apply. Do not apply if you see a boot disk deletion or VM replacement.

Conditional run: when the plan stays within expectations

terraform apply machine-type.tfplan

If something breaks after the change, go back to the previous machine_type and JVM memory and create a new plan.

When Changing the Minecraft Version

A new version can change the world format. Make a fresh backup first and put it through the isolated test in part 06. Then generate the URL and the hash together with the preparation script.

Run

scripts/prepare-server-jar.sh "version-to-install" \
  | tee server-jar-values.txt
nano terraform.tfvars
terraform fmt
scripts/preflight.sh

Paste the printed server_jar_url, server_jar_sha256, and server_java_major together. scripts/startup.sh supports Java 21 and 25. If you change only the URL or only the hash, or leave the old Java major in place, the preflight check stops before the apply.

Run

terraform plan -out=server-version.tfplan
terraform show server-version.tfplan

The expected plan is a VM metadata change. A metadata change alone does not swap the running JAR.

Conditional run: after checking the plan and the backup

terraform apply server-version.tfplan
gcloud compute instances stop "${MINECRAFT_INSTANCE}" \
  --zone="${MINECRAFT_ZONE}"
gcloud compute instances start "${MINECRAFT_INSTANCE}" \
  --zone="${MINECRAFT_ZONE}"

Check java -version and Done (...)! in the new log, and check the client version. If the installed Java major differs from the input value, the startup script fails before it starts the service.

When downgrading, do not hand the current world, already opened by the new version, to the older JAR. Stop the server, prepare the older JAR’s URL, hash, and Java major, and apply them. Restore a compatible backup that was verified on that version, then start the service. Keep a separate archive of the current world before the downgrade so a way back remains.

The Order to Check, from VM to Network

Check

gcloud compute instances describe "${MINECRAFT_INSTANCE}" \
  --zone="${MINECRAFT_ZONE}" \
  --format="value(status,lastStartTimestamp,lastStopTimestamp)"

gcloud compute ssh "${MINECRAFT_INSTANCE}" \
  --zone="${MINECRAFT_ZONE}" \
  --command="sudo systemctl is-active minecraft"

Observed state	Check next	Do not do first
VM TERMINATED	Operations and logs, for a manual stop versus Spot preemption	Loop an automatic start right away
VM RUNNING, SSH fails	Current public IP and OS Login IAM	Open SSH to everyone
SSH works, service failed	The first error in the startup script and the Minecraft journal	Replace the VM
Service active, no Done	World load and memory logs	Change the game firewall
Done present, external connection fails	Listen port, game firewall, client version	Change the SSH rule
World missing after a new boot	The recent plan and the boot disk ID	Keep playing in the empty world

Read the Minecraft log starting from the most recent error.

Check

gcloud compute ssh "${MINECRAFT_INSTANCE}" \
  --zone="${MINECRAFT_ZONE}" \
  --command="sudo journalctl \
    -u minecraft \
    -n 150 \
    --no-pager"

To find in Google Cloud operations why the VM stopped, check the recent list.

Check

gcloud compute operations list \
  --filter="targetLink~/${MINECRAFT_INSTANCE}$" \
  --limit=20

You can limit automatic starts safely only once you can tell a preemption event apart from an operator’s stop. A server that a manual start covers does not need automatic recovery.

Completion Check

• You stop the VM when it is not in use and know which charges remain.
• You can tell apart the expected plan for an administrator IP, a machine type, and a JAR change.
• You recorded which changes need a reboot and which values to roll back to.
• During an incident you check in order: VM, systemd, Minecraft log, network.

The optional feature that restarts only a preempted VM is in Spot VM Automatic Recovery. A server you are finished running needs Procedure for Deleting the Minecraft Server and Its Backups.

References

• Google Cloud: Stop and start a VM instance
• Google Cloud: Spot VMs
• gcloud compute operations list