The Terraform Layout of a Google Cloud Minecraft Server

minecraft-one-root keeps the VPC, firewalls, static IP, VM, and storage in one working directory. The same person reviews and changes them together in a single plan. The function that restarts the VM after a Spot preemption runs on a different schedule with different permissions, so part 09 moves it into a separate working directory.

Verification scope

The Terraform configuration and the shell scripts were checked locally and in a container. A real Google Cloud plan, apply, VM creation, and connection can create cost, so local and container verification did not run them. The current state is local and container verification complete, real Google Cloud apply unverified.

The Terraform Root and State

A Terraform root is the working directory holding the .tf files that run together. The minecraft-one-root download is this server’s root.

minecraft-one-root/
├── README.md                  root overview and command summary
├── versions.tf                provider and Terraform versions
├── variables.tf               inputs and rejection rules
├── project.tf                 required Google Cloud APIs
├── network.tf                 VPC, subnet, IP, and firewalls
├── storage.tf                 backup bucket and permissions
├── compute.tf                 service account and Spot VM
├── outputs.tf                 names and IP used to connect
├── terraform.tfvars.example   input sample (copied and filled in part 04)
├── backend.hcl.example        state bucket config sample (used in part 03)
├── scripts/                   install, check, backup, and restore
└── tests/                     configuration and container tests that run without a real provider

Running the root makes Terraform record in state which resource address maps to which real Google Cloud ID. google_compute_address.minecraft, for instance, is tied to the static IP in the Seoul region. state lives in its own Cloud Storage bucket. The backup bucket and the state bucket differ in purpose and in when they are deleted.

The backend configuration file holds the state bucket name and the object prefix. The prefix works like the folder path where this server’s state sits inside the bucket, keeping things apart when one bucket serves several purposes. terraform.tfvars holds the project, the firewall IP, and the Minecraft JAR values. Both files carry values from a personal environment, so the ZIP ships only the example files and Git excludes the rest.

The Google Cloud Resources That Make Up the Server

Traffic entering the server starts at a firewall and arrives at the VM’s static external IP. A systemd service inside the VM receives requests on the Minecraft Java Edition port.

flowchart LR
    P["Player"] -->|"TCP 25565"| GF["Game firewall"]
    A["Operator"] -->|"TCP 22"| SF["SSH firewall"]
    GF --> IP["Static external IPv4"]
    SF --> IP
    IP --> VM["Spot VM"]
    VM --> MC["minecraft.service"]
    VM -->|"Backup upload"| BB["Backup bucket"]
    TF["Terraform in Cloud Shell"] --> STATE["state bucket"]
    TF --> VPC["VPC and subnet"]
    TF --> VM
    TF --> BB

Each resource takes on the following job.

Resource	Job	Result if it disappears
VPC and subnet	Private network the VM sits in	The VM network cannot be attached.
Game firewall	Allows the Minecraft TCP port	The server runs but nobody connects from outside.
SSH firewall	Allows port 22 only from the operator’s public IPv4	Cloud Shell SSH checks are blocked.
Static external IPv4	Provides the same connection address after a restart	Players have to be given a new address.
VM service account	Lets the VM write and read objects in the backup bucket	Backup upload and verification fail.
Spot VM and boot disk	Holds the Java and Minecraft processes and the current world	The server stops, and deleting the disk removes the world too.
Backup bucket	Keeps the world and operational settings archive and its hash	The recovery copy outside the VM is gone.
state bucket	Keeps Terraform’s management record	The link between code and real resources is lost.

The game firewall defaults to 0.0.0.0/0. That notation is called CIDR: 0.0.0.0/0 means “every address on the Internet”, and the /32 that appears later means “exactly that one address”. The default keeps the port reachable even when a player’s IP changes often, as on a mobile network. In exchange, Minecraft turns the whitelist on from first boot and refuses every player while the whitelist is empty. If only players with a static public IP connect, part 04 narrows each address to /32.

What Changes Together in One Directory

minecraft-one-root keeps the resources in one root because the person who changes them and the moment they are deployed are the same. One operator reviews the firewall, the VM specs, the JAR, and the backup bucket together. Building the server reads every creation from one plan, and shutting it down checks the deletion order of the VM and the network in the same place. After a machine type change, check the VM; after a firewall change, test the connection. An environment where separate teams deploy each resource independently is not what this layout targets.

One root manages only the declarative Google Cloud resources. VM power goes through gcloud compute instances start|stop, while the whitelist and operators change in the Minecraft console. World backup and restore belong to scripts on the VM. Leaving these commands out of Terraform resources keeps the next plan from colliding with daily operator work.

When to Split the Terraform Root

Consider a separate root once any of the following appears.

The person making the change, or the approval authority, differs.
It deploys far more often than the server base.
It needs a different service account and least privilege.
A failure or a deletion on one side must not lock the other side’s state.
Other servers share the same capability.

The Spot recovery in part 09 is such a case. The recovery function has to run after the VM stops, and its code is tested independently. The runtime account is allowed only to read and start the named VM. The Eventarc trigger account only receives events and invokes the function. Splitting it from the server root and state keeps a VM replacement plan out of the way when the recovery code changes.

Splitting roots too finely too early multiplies backends and apply ordering. Split apart the VPC, IP, and VM that one person always changes together, and you take on passing outputs and managing state dependencies.

Estimated Cost and Spot Interruption

Price depends on region, hours used, disk, and egress. Budgeting against a fixed amount leads to a wrong call once the price list changes. Immediately before apply, reopen the calculator and enter the VM, disk, address, and storage conditions from the plan.

Check: screen names as of July 31, 2026

Open the Google Cloud Pricing Calculator.
Under Compute Engine, choose Seoul (asia-northeast3) as the region.
Choose e2-standard-2 for the machine type and Spot for the provisioning model.
Enter the hours you will actually keep it on for a month. Calculate 24-hour operation and running only when needed as two separate cases.
For the boot disk, enter Balanced persistent disk and 30 GiB.
Check the static external IPv4 line. While the address stays attached to a stopped VM, Google Cloud counts that address as in use.
Enter the expected storage for state and backups under Cloud Storage. Multiply the number of backups by the retention period for a rough size.
Add the network egress sent to players.

Include network egress in the estimate. On the August 2026 public price list, the first 1 TiB tier of Premium Tier internet traffic destined for Korea costs $0.19 per GiB. The actual amount depends on the source region, destination, and monthly usage, so check the price list immediately before apply and the Network line of the billing report after operation.

The result is an estimate for the moment you entered it. Taxes, discounts, price list changes, and real usage patterns move the actual bill. The budget alert in part 02 also only sends a notification; it blocks no cost.

Stopping the VM stops the vCPU and memory charges. Charges for the boot disk, reserved external IPv4, and backup and state objects can continue. In part 11 you check these items again against the resource list and the billing report.

A Spot VM costs less than a standard VM, but Google Cloud can reclaim the capacity. compute.tf sets the preemption action to STOP, so the VM state becomes TERMINATED. Automatic restart is not part of the base configuration. Check the backup restore in part 06 and the manual start in part 08 first. Only readers who need automatic recovery add part 09.

Before creating resources, use Project and Cloud Shell Preparation to confirm the project, billing link, and execution environment.