The original software of the Apollo 11 is still available on GitHub and anyone can read, download, and study it today. Although the story often reappears on social media as if it were a recent news, the repository has been published for years and contains the source code of the Apollo Guidance Computer from the command module and lunar module of the mission that achieved the first crewed moon landing.
The main project, maintained by Chris Garry, includes two major blocks: Comanche055 for the Command Module and Luminary099 for the Lunar Module. The repository itself explains that the material was digitized from copies preserved at the MIT Museum with the help of the Virtual AGC project, and presents it as public domain code.
That alone would make it a highly valuable historical artifact, but there’s an even more interesting aspect for a tech and cloud-focused audience: this code is not just from the past, it also helps understand very current debates about efficiency, observability, critical software, and emulation. In an industry obsessed with scaling, consuming more, and adding layers, Apollo 11 reminds us that a core part of engineering is doing a lot with almost nothing.
Long before the cloud, there was already an obsession with optimization
The figures of the Apollo Guidance Computer still impress today. According to Virtual AGC documentation, the system had 2,048 words of RAM, equivalent to 3,840 bytes, and 36,864 words of read-only memory, equivalent to 69,120 bytes. Its execution capacity was around 85,000 instructions per second. With this hardware, NASA and MIT managed to build a system capable of navigation, processing inertial unit data, and assisting in critical maneuvers during the lunar mission.
Viewed from the present, where any modern cloud service relies on layers of virtualization, containers, observability, software-defined networking, and massive memory volumes, the contrast is almost stark. But precisely because of this, the repository has pedagogical value: it exposes a software culture where each instruction mattered, every block had to be justified, and reliability was achieved not by “throwing more resources,” but through rigorous design and extreme system control.
It was also not a monolithic software. The repository makes it clear that Apollo 11 used two different programs because the two spacecraft had different missions. Comanche055 was for the command module’s guidance computer, while Luminary099 was designed for the lunar module. This technical detail is very revealing: even with shared hardware, the software was tailored to specific functions, which remains a key idea in cloud and edge architecture today, where not all workloads must run the same way or in the same environment.
From computing heritage to modern emulation
The value of the project isn’t limited to examining assembly listings. The Virtual AGC repository enables assembling and emulating much of the Apollo software, including tools like yaYUL and simulators for the AGC and some peripherals. In other words, it’s not just about preserving the code as a historical artifact, but about maintaining a live environment that allows experimentation with modern systems.
This aspect connects very well with today’s cloud world. Emulation and virtualization are two pillars of modern infrastructure, and Virtual AGC represents an almost archaeological version of that same logic: encapsulating an ancient system, reproducing its behavior, and making it accessible on contemporary platforms. In fact, its documentation states it can even be deployed with Docker, making it easy to run the simulators without depending on a complex local environment. For a technical audience, this blend of heritage, open source, and containerization is far more interesting than it might seem at first glance.
Furthermore, Garry’s repository preserves parts of the human and technical context of the project. Under the approvals section, among other names, Margaret H. Hamilton appears as Colossus Programming Leader, highlighting the decisive role of one of the most important figures in computing history. This is not a minor detail: this code not only allows studying a historic architecture, but also reveals how teams were organized, programs validated, and systems documented that could not afford to fail.
Why this code matters to the tech industry today
By 2026, with generative AI boosting computational demand, the tech debate revolves around GPUs, energy efficiency, edge inference, and infrastructure sovereignty. In that context, Apollo 11 doesn’t provide direct answers, but offers a very relevant lesson: critical systems engineering improves when there is discipline over resources, interfaces, and software behavior. In that sense, AGC is less a nostalgic relic and more an uncomfortable reminder of how much modern software depends on abundance to manage complexity.
There’s also a significant cultural dimension for the open source and cloud ecosystem. That this code is accessible on GitHub, with thousands of stars, forks, and contributions, proves that interest in historical software is not marginal. There remains an active community eager to read, correct transcriptions, compare it with original scans, and maintain tools to keep it executable. That transforms the repository into more than just a tribute: it’s a showcase of how open source can also serve as a infrastructure for technological preservation.
Ultimately, perhaps that’s why Apollo 11’s code remains so fascinating. Because it symbolizes not only a space feat, but also a way of building software that, even today, in the era of massive cloud and AI, continues to impress with its clarity, efficiency, and technical ambition.
Frequently Asked Questions
Where is the original Apollo 11 code available?
It’s published on GitHub in the repository chrislgarry/Apollo-11, containing Comanche055 and Luminary099.
Can the Apollo 11 software be run today?
Yes. The Virtual AGC project offers tools to assemble and emulate the Apollo Guidance Computer software on modern systems.
How much memory did the Apollo 11 computer have?
According to Virtual AGC, the AGC had 3,840 bytes of RAM and 69,120 bytes of read-only memory.
Why is this code relevant to cloud and tech media today?
Because it allows studying extreme efficiency, critical software, emulation, open source preservation, and system design within very limited resource contexts—topics that remain relevant in modern infrastructure.