60-minute Minecraft server deployment with AI

The latest version of System Initiative has proved a great fit for use with AI solutions like Claude Code, so I decided to test it out by giving it as few instructions as possible, and seeing how far it could go at creating a project I thought was simple: Deploying a publicly accessible Minecraft server, in under an hour.

First strategy: The one-shot approach

After completing onboarding, I was greeted by two components: Region and Credential. I set up my screen to view both Claude, with the AI Agent configured, and the SI app.

I then told the AI to create me a Minecraft server with an S3 bucket that stored the server data for me:

It created a change set and added the components that it thought were required. After navigating to that changeset, which Claude named “minecraft-server-infrastructure”, I took a quick look at what it did. Having checked that the simulation made sense, I applied the change set to HEAD, which triggers the creation of actual resources.

Real-world assets are modified on System Initiative via Actions. Above and to the right, we can see a list of the actions that will be executed as a consequence of the change set being applied: Create the S3 bucket, create IAM configurations, the security group, and the EC2 instance.

I then applied the change set to see the results:

The Consequences: fixing up my first attempt

As you can imagine by the amount of red on the screenshot, all of the actions failed. So I told Claude to resolve any issues. It can do that by looking at the actual errors that our actions returned:

Here’s what Claude responded:

After running some agent requests, Claude is confident that it has fixed our issues. In the review screen, I can see the changes it’s proposing:

But there’s an issue here! See how all components on the left have a green plus sign next to them? That means it created duplicate components instead of fixing the failed ones. And it didn’t even delete the old components! I made a prompt to understand its approach:

It recognized that it could have fixed the components themselves, and created another change set with the right fixes:

Upon examining the review screen, it has made the correct changes. The yellow tilde means modified, and we can see here the bucket name change, as an example:

The final error was about not being able to create the IAM policy for the S3 bucket, which made me realize I was trying to do too much at once. I asked Claude to remove all of the S3-related components and configurations and just bring up the server.

Success! In theory.

The lights are on, but no one is home: Fixing the EC2 instance configs

Now, to run minecraft and access the server:

For some reason, the client cannot reach the game server. At this point I had to double-check the server in the AWS console. The instance was up, and I was able to ping it, so my next thought was to check the user data, which contains the script AWS runs after deploying the instances. Claude had created that for us in the first step, so let’s ask more about it:

I didn’t have to check any details about the deployment strategy up to this point, so this gives a much clearer picture of it: We’re installing Docker on the instance, and running an existing container image for a Minecraft server, binding the data directory so we can control it from the host. So what’s wrong here?

Even without me asking for an analysis, Claude had already auto-detected a port mapping error in the userdata and suggested the fix:

Before recreating the instance, I also decided to check that it was using a valid Docker image by running it myself. This was the result:

The important part here is the last three lines, especially: "repository does not exist or may require ‘docker login’". Claude should be able to deal with that too.

Claude searched the web for a correct Docker image and used it. I also needed to ask it to terminate and recreate the EC2 instance, since the User Data code only runs at first boot. With that, all I had to do was ask Claude for the public IP of the server:

And it works!

Conclusion

I think it’s worth mentioning that I did not know how to do any of that before. I had good knowledge of the building blocks, Docker, and AWS itself, but had never deployed a video game server. Pairing with Claude helped bridge that gap — by starting with a very close to correct architecture and then working together to implement it.

Of course, there’s still more work to be done: we could still go back and configure S3 storage, or try to lock down which IPs can access the server. We could even ask Claude to review the work and suggest improvements! But this is more than enough to have a playable and fully configurable Minecraft server.