Minecraft Terraform in Practice
19 records
Build and Operate
- Why Manage a Minecraft Server with Terraform The Google Cloud resources behind one VM and what Terraform configuration and state manage
- The Terraform Layout of a Google Cloud Minecraft Server A layout that keeps VPC, firewalls, static IP, VM, permissions, and storage in one working directory
- Preparing the Google Cloud Project and Cloud Shell From creating the project to linking billing, setting a budget alert, and installing Terraform in Cloud Shell
- Terraform Authentication and Remote State The deploy account in Cloud Shell, the IAM roles it needs, and the Cloud Storage backend that holds state
- Preparing the Minecraft Server JAR and Terraform Inputs Official server JAR, Java version, SHA-256, EULA, firewall IP, and bucket names
- Applying a Terraform Plan and Connecting to Minecraft Reading the first Terraform plan, approving the cost, booting the VM, and connecting from Java Edition
- Minecraft World Backup and Restore Test Backing up the world and operational configuration, verifying SHA-256, and testing restore away from the production server
- Moving an Existing Minecraft World to Google Cloud Checking an existing world archive, staging it on the VM, replacing the test world, connecting, and creating a new backup
- Minecraft Server Power and Version Changes Starting and stopping the VM and changing the administrator IP, machine type, and Minecraft and Java versions
- Restarting the Minecraft Server After a Spot Preemption A separate Terraform root that matches only Spot preemptions and starts the same VM again
- Procedure for Deleting the Minecraft Server and Its Backups Keeping the last backup, removing the Spot recovery root, disabling deletion protection, and destroying the server
- Cleaning Up Terraform State and Remaining Google Cloud Costs Removing empty state objects and the backend bucket, then checking the billable resources and IAM left in the project
Reading Back the 2025 Setup
- Splitting One Terraform Root into Three How a single main.tf that accumulated server, recovery, and backup settings became three working directories with separate deployment units
- Deploying the Server, Recovery, and Backup Separately How the server, recovery function, and backup cleanup were deployed from three working directories with independent plan and apply cycles
- The Deployment Contract in VM Metadata and the Startup Script How Terraform inputs became files and systemd services at boot, including values with no consuming code
- ZIP Deployments and the Terraform Import Record How deployment archives were built and existing Google Cloud resources were attached to Terraform state
- Overlapping Resource Ownership Across Three Working Directories Resources duplicated across three states and connections maintained through manually copied names
- Secrets Spread Across HCL, State, Metadata, and a ZIP How one variable default spread to six places, and what a history rewrite could not undo
- Migrating the 2025 Terraform Configuration to the Current Baseline Separating the product settings I would choose now from the original design defects, and the criteria for picking a migration path you can reverse