Why Manage a Minecraft Server with Terraform

In the Google Cloud Console, selecting an operating system, region, machine type, and disk starts the first VM quickly. That lightweight path fits a server you test for a day and then delete.

Reserving a static external IP and opening the game port and the SSH port separately adds more to manage. A backup store and a service account are needed too. The screen shows one server, but inside Google Cloud several resources are linked to each other. Months later, every time you change the specs or shut the server down, you have to find the values you first picked all over again.

A server built in the Console can continue running. If you plan to rebuild the same configuration, or to change and delete several resources together, Terraform code and state provide the reference for that later work.

The Console for a First Test

For a server you test once, the Compute Engine screen can create the VM without a configuration file. After creation, the current operating system, region, machine type, and disk remain visible on screen.

The Console keeps the finished resources but not the order you clicked. The reason you chose the Seoul region, or the IP you put in the firewall, has to be written down separately. Without those notes, rebuilding the server falls back on memory.

gcloud commands turn the clicks into terminal commands. Saved commands repeat, but when an existing resource differs from what a command expects, the operator decides the next move. A shell script can hold that branching. In exchange, you write the create, update, and delete order yourself.

Resources Created with the VM

Once external access and backups are in scope, the VM alone is not enough. minecraft-one-root creates the following Google Cloud resources.

Google Cloud project
├── VPC and subnet
├── Game port firewall and SSH firewall
├── Static external IPv4
├── Dedicated service account
├── Spot VM and boot disk
├── World backup bucket
└── Terraform state bucket

Deleting the VM can leave the static IP and the buckets behind. Delete the state bucket first, and Terraform loses the link between the code and the real resources. The VM, static IP, and two buckets have different deletion conditions and schedules.

Setup and Repeated Work by Tool

Whether you test the server once or run it for months while changing it decides which tool fits and how much setup time it takes.

Method	First build	Reviewing changes before apply	Reproducing the configuration	Tracking and deleting resources	World protection
Console	Fastest	Screen by screen	Click history has to be recorded separately	Has to be found across several screens	Separate backup required
`gcloud`	Commands to learn	Command by command	Repeatable from a command log	Names and order managed by hand	Separate backup required
Shell script	Script to write	Depends on the output you wrote	Possible once branching is implemented	Create, update, and delete logic written by hand	Separate backup required
Terraform	HCL and state to learn	Full difference through `plan`	Plannable from the same code and inputs	state links code addresses to resources	Separate backup required

HCL is the configuration file syntax Terraform uses to define resources. State stores the mapping between Terraform addresses and real resources. The server’s Terraform layout shows where both files live.

For the first VM alone, Terraform is slower. You learn the HCL syntax and prepare a place to keep state. In exchange, a spec change shows its related edits together in plan, and at shutdown time state points to the resources that remain.

The Change List You Read Before Applying

A Terraform file states the desired state. Change the machine type from e2-standard-2 to another value, run terraform plan, and Terraform compares the current state with the new configuration.

Code and inputs ──┐
                  ├─ terraform plan ── planned create, update, replace, delete
Current state ────┘

plan alone changes nothing. The output shows whether the VM is updated in place, has to be stopped, or is replaced with a new resource. The bundled review-plan.sh stops when a first deployment plan mixes in an update, a deletion, or a replacement.

Keeping a plan file around and applying it much later causes trouble. Resources can change in the Console in the meantime. Create the plan you will apply right before applying it, and read it yourself.

The State That Links Code to the Real VM

state links a Terraform address such as google_compute_instance.minecraft to a real Compute Engine VM. With that record, Terraform tells apart updating an existing VM from creating a new one. minecraft-one-root uses a Cloud Storage backend so the record survives the end of a Cloud Shell session.

state can hold resource attributes. Put a password or a token into a Terraform input and the sensitive value can stay in state as well. minecraft-one-root creates no Minecraft console password and restricts access to the state bucket. That is why the state file does not go into Git or a public ZIP.

state does not contain world files. /srv/minecraft/world on the VM can be corrupted while state stays intact. Terraform remembers Google Cloud resources and their attributes; a separate backup preserves game data.

State to Check Separately After Apply

The Terraform in minecraft-one-root creates the VPC, firewalls, static IP, service account, VM, and backup bucket. VM metadata carries the startup script along with the Minecraft JAR URL, hash, and Java version. After boot, the startup script prepares Java and the systemd service.

Once terraform apply finishes, check several different states in turn.

Check in the Compute Engine API that the VM is RUNNING.
Check in systemctl that minecraft.service is active.
Check the Minecraft log for Done (...)!.
Manage the whitelist and operators from the Minecraft console.
The backup script compresses the world and the operational settings and uploads them to Cloud Storage.
An isolated restore test loads the archive into a real Minecraft process.

A successful Terraform apply means the Google Cloud resources were created as planned. Minecraft readiness shows up as Done (...)! in the server log. A backup is usable for recovery only after it passes a test that loads the world on a separate server.

Servers the Console Alone Covers

For a server like the following, building it in the Console and taking notes is lighter.

It is a test server used for a day or a weekend and then deleted.
There is no plan to rebuild the same configuration.
One person can clean up every resource created in the Console.
It uses only a new world that may disappear with the VM.

If you plan to start and stop the server over months, change its specifications and versions, or rebuild the same configuration, you can use Terraform’s code and state. At shutdown, state also identifies the resources Terraform still manages.

Choosing Terraform still leaves the world backup to prepare separately. Do not move an important existing world onto this server until it passes the isolated restore test in part 06.

The build needs a Google Cloud billing account and a Minecraft Java Edition client. New customers eligible for the free trial receive $300 in credit valid for 90 days after verifying their identity with a supported payment method. The trial does not turn into automatic charges unless they upgrade to a paid account. The steps for checking the paid-account status and budget alert are in Project and Cloud Shell Preparation. A budget alert reports spending but does not stop charges on its own.