Building the First Prototype with Proxmox

The Beginning of the Prototype

After finalizing the idea for my “Mini AWS,” we officially started building the first prototype. The goal was simple (at least in theory):

Create a web platform where users could log in, create VMs or containers, choose specifications, and instantly get access—just like AWS, but on a smaller scale.

The flow we imagined was something like this:

• User logs in
• They see options like Create VM or Create Container
• They pick RAM, CPU cores, storage, etc., from dropdown menus
• They hit Create
• The frontend sends the request to our backend Node.js API
• The backend communicates with Proxmox API
• Proxmox creates the requested VM or container
• We return an SSH connection string and login details to the user

At that time, we were only using password-based access, not SSH keys. Still, the whole system worked surprisingly well on our local network.

Playing With the Proxmox API

Proxmox’s API turned out to be pretty great. But since we weren’t experts yet, it took a lot of trial and error to get everything working smoothly. Eventually, we managed to connect our Node.js backend to Proxmox, trigger VM/container creation, and send back the connection details to the frontend.

When we saw our first automatically created VM boot up, it felt amazing.

The IP Problem

But soon we hit a huge challenge—the IP addressing problem.

On our local network, everything worked perfectly. We were generating private IP-based connection strings and connecting to those VMs/containers without any issues.

But then I realized:

“What happens when this becomes a real hosted website? How will we assign IPs to every user's VM or container?”

In a real cloud environment:

• Each virtual machine needs its own unique internal network
• Multiple users should not clash
• Users cannot access or destroy each other’s resources
• Isolated networks must be dynamically created

For Minecraft, it was simple—everyone connected to one server. But for a cloud platform, every user needed individual, isolated environments.

This is where things got complicated.

The Project Halts (Temporarily)

Before we could figure out the networking model properly, our second-last semester exams arrived. We had no choice but to pause development and focus on studies.

We submitted the prototype in its half-baked state. Teachers loved it, classmates were impressed… But I wasn’t satisfied. I knew it was far from what I imagined.

A Silver Lining — The Internship

Even though the project was incomplete, it still gave me something important: an internship opportunity.

A company saw the project, loved the concept, and offered me a 6-month internship based on it. That experience helped me grow a lot, learn real-world development practices, and gain confidence.

After completing my internship, my college journey officially ended. But the story of “Mini AWS” didn’t.

We never finished the first version completely—but that only opened the door for something bigger.