Restarting Mycelium

I recently restarted work on Mycelium.

The project has been sitting quietly for a while. The idea never really went away; I just did not have the time to give it the attention it needed. Now I finally have some room to return to it, revisit the logic behind the original concept, and question the assumptions I made the first time around.

This is less about reviving an old codebase and more about returning to an unfinished thought.

Explore the development preview at mycelium.situ.io →

Mycelium is still under active development. Right now, its functionality is not ready for real-world architecture work or production use.

What Mycelium is

Mycelium is a visual architecture workbench for modeling cloud and on-prem systems. It is designed for Azure, AWS, Google Cloud, Microsoft 365, and on-prem resources, with an emphasis on keeping the structure of a system understandable as it grows.

The aim is to work from one canonical model. Resources can be placed inside the regions, networks, and subnets where they belong; connections and dependencies can be reviewed; and the same system can move between 2D, 3D, architecture, Mermaid, and infrastructure code views without being redrawn from scratch.

It is still a development preview, but the current version is available at mycelium.situ.io. There is also a scratch editor for trying the core ideas without first setting up a project.

The original idea

The first version of Mycelium came from a frustration I have had for years: most architecture diagrams are pictures of a system, not models of one.

They are useful for a meeting or a design review, but they quickly drift away from reality. A box might represent a virtual network, a database, a tenant, or an application, yet the diagram itself often has no understanding of the difference. The meaning lives in the person who drew it, in a legend off to the side, or in a document that stops being maintained.

I wanted to explore what happens when the diagram understands more of the system it represents.

A resource should keep its provider identity. A subnet should belong to a network. A connection should be valid for the resources on either end. A change in one view should still be the same change everywhere else. The visual layer should make the architecture easier to read, but the underlying model should remain useful beyond the canvas.

That was the part of Mycelium I found most interesting. It still is.

Revisiting the logic

Coming back to the project with some distance has been useful. I can see where the early implementation followed the interface too closely and where the model needs to do more of the work.

The questions I am revisiting now are mostly below the surface:

What makes a resource belong somewhere? Containment should describe real architectural boundaries, not just where a box happens to be drawn.

What makes a connection meaningful? A line between two resources should carry context and should be able to tell us when the relationship is unsupported or incomplete.

How should one model serve different views? A 2D canvas, a 3D view, an architecture document, and generated infrastructure code all need different presentations, but they should not become separate versions of the truth.

How much should the platform assume? Provider awareness is valuable, but it should guide the user without turning the tool into a rigid form that only permits one way to design a system.

These are not the most visible parts of the product, but they determine whether Mycelium becomes genuinely useful or just another attractive diagramming tool.

Starting again, deliberately

There is still a lot to work through. The resource model needs to grow, the rules around containment and connections need more testing, and the path from visual design to delivery artifacts needs to earn trust.

That is exactly why I restarted it.

I finally have the time to examine the thinking behind Mycelium instead of only pushing the interface forward. I want to keep the project small enough to question, clear enough to explain, and practical enough to use on real architecture work.

For now, Mycelium is open as a development preview. I will keep sharing what changes as I work back through the original idea and see where it leads this time.