Carlos Cortez 🇵🇪 [AWS Hero] for AWS Heroes

Posted on Jul 13

I Built a CI/CD Pipeline and an AWS Console Inside Minecraft

What if your Minecraft crafting system worked like cloud infrastructure? Not just "put items in a grid and get a result" — but actual deployment pipelines with processing time, consoles that randomize configurations like spinning up instances, and a tiered progression that mirrors going from dev to staging to production.

In Part 2, we made the swords look good. Now we make the infrastructure that produces them feel like real cloud operations.

🎮 The learning angle: Every machine in this mod maps to a real cloud concept. The Cloud Deployer IS a CI/CD pipeline — it takes source code (Inactive Core) and produces a deployable artifact (Active Core) over time. The Cloud Console IS the AWS Console — you configure your resources (swords) with randomized parameters within tier-specific ranges.

The Cloud Deployer — Your CI/CD Pipeline

In the real world, you don't just write code and instantly have a running service. You push to a repo, a pipeline picks it up, builds it, tests it, and deploys it. That takes time.

The Cloud Deployer works the same way:

Input: Inactive Sword Core (your "source code")
Process: 8-15 seconds of "deployment" (progress bar)
Output: Active Sword Core (your "deployed artifact")

Two tiers of deployer:

Cloud Deployer (Low) — 15 seconds, produces Basic Core. Like a free-tier CI pipeline.
Cloud Deployer (Medium) — 8 seconds, produces Advanced Core. Like upgrading to a faster build runner.

The Basic Core only works for Tier 1 swords (CloudWatch). The Advanced Core unlocks everything else. Just like in real cloud — your free tier has limitations, but upgrading your infrastructure unlocks more powerful services.

The Code: A BlockEntity with a Timer

public class CloudDeployerBlockEntity extends BlockEntity implements TickableBlockEntity {
    private int progress = 0;
    private final int maxProgress; // 15s or 8s depending on tier

    @Override
    public void tick() {
        if (hasInput() && !hasOutput()) {
            progress++;
            if (progress >= maxProgress) {
                craftOutput(); // Inactive Core → Active Core
                progress = 0;
            }
        }
    }
}

Simple, but the game feel is powerful. You place your core, watch the progress bar fill, and get your artifact. It feels like deploying.

The Cloud Console — Randomized Configuration

Here's where it gets interesting. The Cloud Console is a block where you place a sword and it randomizes its stats within tier-specific ranges.

Think of it like the AWS Console where you configure an EC2 instance:

You choose your instance type (tier)
You get specific specs within that family's range
Higher tiers give better ranges

Console Tier	Damage Range	Speed Range	Cooldown Range
Low	-3 to +5	-2 to +1	-2s to 0s
Medium	-3 to +10	-2 to +2	-4s to 0s
Creative	-3 to +10	-2 to +3	-5s to 0s

Every time you use the console, you get a different roll. Maybe your Lambda sword gets +8 damage but -1 speed. Maybe next time it's +3 damage but +2 speed. It's like choosing between compute-optimized and memory-optimized instances — tradeoffs everywhere.

public enum ConsoleTier {
    LOW(-3, 5, -2, 1, -2, 0),
    MEDIUM(-3, 10, -2, 2, -4, 0),
    CREATIVE(-3, 10, -2, 3, -5, 0);

    // Random roll within range
    public int rollDamage(Random random) {
        return random.nextBetween(minDmg, maxDmg);
    }
}

Deprecated Swords — Legacy Migration

One of my favorite design decisions: Deprecated Swords.

These are weaker versions of each sword that drop as loot in dungeons and structures. They have iron-level stats, no abilities, and a tooltip that says: "A legacy service awaiting migration..."

Sound familiar? It's the cloud migration story. You find a legacy system (deprecated sword in a dungeon), and you can either:

Use it as-is — works, but limited
Migrate it — take it to the Smithing Table with an Active Core and upgrade it to the full version

The migration recipe is cheaper than crafting from scratch, just like in real cloud — migrating existing workloads is often more cost-effective than rebuilding.

The Progression: Dev → Staging → Production

The full player journey maps perfectly to cloud maturity:

EARLY GAME (Overworld) = Development Environment
  Mine Cloud Ore → Basic materials
  → Cloud Console (Low): limited configuration
  → Cloud Deployer (Low): slow deployments, basic artifacts
  → Only Sword of CloudWatch accessible (monitoring first!)

MID GAME (Nether) = Staging Environment  
  Mine Nether Cloud Ore → Advanced materials
  → Cloud Console (Medium): better configuration ranges
  → Cloud Deployer (Medium): faster deployments, advanced artifacts
  → All swords accessible (full service catalog)

Notice that CloudWatch is the first sword you can craft. In real AWS, observability should be the first thing you set up. The game teaches this naturally.

EMI Integration — Your Service Catalog

EMI (Extremely Mod Integration) is Minecraft's recipe viewer. We added a custom "Deploying" category that shows:

What goes in (Inactive Core)
What comes out (Active Core)
How long it takes (progress bar animation)

It's literally a service catalog. Players can browse all available "deployments" and see what infrastructure they need.

Smithing Table — Infrastructure as Code

The Smithing Table recipes follow a pattern:

Template: Active Sword Core (your deployment artifact)
Base: Service-specific component (Lambda Chip, Processor Core, etc.)
Addition: Cloud material (Blazing Shard, Network Cable, etc.)

This is Infrastructure as Code. You define your template (the core), specify your service (the base component), and add your configuration (the addition). The Smithing Table "applies" your configuration and produces the final resource.

Lessons Learned

Challenge	Solution
Randomized stats feel unfair	Show the ranges clearly in tooltip
Deployment time feels slow	Add progress bar + particles
Too many recipes to remember	EMI integration is essential
Tier progression unclear	Visual differentiation (colors per tier)
Legacy migration concept	Deprecated swords as loot → upgrade path

What's Next

We have swords, textures, machines, and progression. But we're still on Minecraft 1.21.1 with a mod called "AWS Swords." In the next post, we'll rebrand to Cloud Swords, add a full villager economy with 7 cloud professions, and backport everything to Minecraft 1.20.1 for compatibility with the biggest modpacks.

Because a mod isn't real until it works alongside 650 other mods.

Full source code on GitHub.

Connect with me:

I'm Carlos Cortez, this is Breaking the Cloud, and today we deployed swords to production. See you in the next one! 🚀

DEV Community