CloudSim: Cloud Server Simulator
March 21, 2026
I built a Python package on PyPI that simulates cloud servers in your terminal. SSH, networking, server management, all locally and for free. Also built CloudSim Academy with AI voice demos.
What is it?
I built CloudSim as a Python package that lets me simulate cloud-style server workflows directly in the terminal. You can create fake servers, connect with a simulated SSH session, and play with infrastructure ideas locally without paying for real cloud resources.
Alongside that, I built CloudSim Academy, which is a tutorial site for the project with AI-generated voice explanations. So this ended up being both a CLI tool and a small content platform around it.
How it works
The CLI is installed like a normal Python package, and the commands operate on a local state file that tracks the fake cloud resources. When I create a server, start a service, or connect over simulated SSH, I am really reading and updating that local state model.
The Academy site is separate. It uses pre-generated audio files for the lessons so the educational layer stays cheap and simple to host. I liked that split because it kept the teaching layer static while the CLI did the interactive work.
Under the hood: PyPI packaging
This project forced me to understand Python packaging more properly. The package metadata and CLI entry points live in `pyproject.toml`, and that is what makes the `cloudsim` command available after install. Build the wheel and source distribution, upload them, and the package becomes a real installable tool instead of just a repo.
That may sound basic, but there is a big difference between writing a Python script and shipping a package that behaves like a product. Packaging, entry points, versioning, and publishing are what turn local code into something other people can actually install cleanly.
Amazon Polly for the Academy site
For the tutorial site, I used Amazon Polly to generate the lesson audio. I did not want live text-to-speech calls on every page load, so I pre-generated the MP3 files and served them as static assets instead.
That made the site much cheaper and simpler to run. The tradeoff is that I have to regenerate the audio when the lesson text changes, but that is totally fine for content that does not update every day. It is a good example of choosing static generation over unnecessary runtime complexity.
Simulating stateful systems
The most interesting conceptual part of this project was the state model. The fake servers, IPs, and resource metadata all live in local JSON. Every command reads that state, modifies it, and writes it back.
That sounds tiny, but it taught me a lot about how infrastructure tools think. Once I built my own little state file system, Terraform’s state model made way more sense to me. I could see the same core pattern on a much smaller scale.
Key takeaways
- PyPI packaging: pyproject.toml, entry points, twine upload, wheel vs sdist
- Click library: subcommands, options, help text, REPL-style interfaces
- Amazon Polly neural TTS: voice selection, pre-generation to S3, audio serving
- Local JSON as a state store for CLI tools, same pattern as Terraform state
- S3 pre-signed URLs and CloudFront for serving static audio assets