Archyl – The modern platform for C4 model documentation(archyl.com)
archyl.com
Archyl – The modern platform for C4 model documentation
https://www.archyl.com/
9 comments
Has anyone created a set of C4 diagrams for fundamental things, like the various processes that might all be running on an idle Debian/CentOS/Alpine system?
Visualize your systems, discover architecture from code, and keep everything in sync.
> Visualize your systems, discover architecture from code, and keep everything in sync.
Not everything.
Lock up your c4 models in a proprietary platform instead of a diagrams-as-code.
Connect to git not to bidirectionally sync c4 models in a preservable text format, but to slurp more info into the golden-handcuffs source of truth.
Avoid detailing how invention intellectual property disclosure and platform security reconnaissance are protected against.
(On the outbound sync, see Structurizer or plant uml c4 for text portable examples, or icepanel.io for JSON metadata export of full models.)
It's a beautiful product and we'd authorize our teams to use it instantly, except for the philosophical and practical non-starters, and we'd need to have a deep understanding for the security model around keys-to-the-kingdom systems.
Not everything.
Lock up your c4 models in a proprietary platform instead of a diagrams-as-code.
Connect to git not to bidirectionally sync c4 models in a preservable text format, but to slurp more info into the golden-handcuffs source of truth.
Avoid detailing how invention intellectual property disclosure and platform security reconnaissance are protected against.
(On the outbound sync, see Structurizer or plant uml c4 for text portable examples, or icepanel.io for JSON metadata export of full models.)
It's a beautiful product and we'd authorize our teams to use it instantly, except for the philosophical and practical non-starters, and we'd need to have a deep understanding for the security model around keys-to-the-kingdom systems.
Fair points, thanks for laying them out clearly.
A few clarifications:
1. We don't aim to replace diagrams-as-code or lock teams out of portable formats. Archyl focuses on discovering and keeping architecture in sync with reality: export and text-based representations are on the roadmap because portability matters.
2. Git integration today is read-only by design. We intentionally avoid bidirectional mutation of source or models until we can guarantee determinism and auditability.
3. We do not treat Archyl as a "golden source of truth" for code or IP. The goal is derived metadata and visualization, not ownership of your system definition.
4. Security is taken seriously: scoped access, least-privilege credentials, and no persistence of sensitive source artifacts beyond what's required for analysis. We're working on publishing a deeper security model to make this more explicit.
The philosophy tension you're pointing out is real, and we're trying to earn trust there rather than hand-wave it away. Appreciate the thoughtful critique.
A few clarifications:
1. We don't aim to replace diagrams-as-code or lock teams out of portable formats. Archyl focuses on discovering and keeping architecture in sync with reality: export and text-based representations are on the roadmap because portability matters.
2. Git integration today is read-only by design. We intentionally avoid bidirectional mutation of source or models until we can guarantee determinism and auditability.
3. We do not treat Archyl as a "golden source of truth" for code or IP. The goal is derived metadata and visualization, not ownership of your system definition.
4. Security is taken seriously: scoped access, least-privilege credentials, and no persistence of sensitive source artifacts beyond what's required for analysis. We're working on publishing a deeper security model to make this more explicit.
The philosophy tension you're pointing out is real, and we're trying to earn trust there rather than hand-wave it away. Appreciate the thoughtful critique.
Appreciate the reply and thanks for the dialogue.
> 2. Git integration today is read-only by design. We intentionally avoid bidirectional mutation of source or models until we can guarantee determinism and auditability.
Our CI/CD regenerates our business and tech knowledge site with full business, product, system, and code docs on every build.
Lack of sync makes your product unusable for us, even though we're your most target market since we are entirely sold on, and practicing, the ethos that leads to this product.
We were among the first users/supporters of Structurizer. We were among the first users of icepanel.io, found it couldn't support our scope*, but ... paid for it anyway (!!!) just to support the concept.
[* Note: It only took them a couple quarters of work to be able to support our or anyone's, scope.]
Also support the work other teams are doing to make smarter (more humane) layouts, we even pay for commercial layout engines if they are drop-in for open source.
We do all this not just because this is the right way to do it even as a solo engineer, but anyone working in this space is contributing towards making architectural thinking and communication as common and portable as markdown, necessary to bridge the silos within most organizations of any scale.
OTOH, if the product doesn't squarely support an ecosystem rather than silo philosophy, we can't (won't) back it. Still, whatever your direction, we applaud working to make a business in this space.
> 2. Git integration today is read-only by design. We intentionally avoid bidirectional mutation of source or models until we can guarantee determinism and auditability.
Our CI/CD regenerates our business and tech knowledge site with full business, product, system, and code docs on every build.
Lack of sync makes your product unusable for us, even though we're your most target market since we are entirely sold on, and practicing, the ethos that leads to this product.
We were among the first users/supporters of Structurizer. We were among the first users of icepanel.io, found it couldn't support our scope*, but ... paid for it anyway (!!!) just to support the concept.
[* Note: It only took them a couple quarters of work to be able to support our or anyone's, scope.]
Also support the work other teams are doing to make smarter (more humane) layouts, we even pay for commercial layout engines if they are drop-in for open source.
We do all this not just because this is the right way to do it even as a solo engineer, but anyone working in this space is contributing towards making architectural thinking and communication as common and portable as markdown, necessary to bridge the silos within most organizations of any scale.
OTOH, if the product doesn't squarely support an ecosystem rather than silo philosophy, we can't (won't) back it. Still, whatever your direction, we applaud working to make a business in this space.
A bit off topic, but I am curious about your experience with Structurizer. My experience wasn't so positive (albeit the general incentive that it's open-source and local).
It's pretty ungainly for anything more than toy models. The rendering's rather hideous too.
If you just want pretty C4 models, Draw.io is your best bet. But then you lose all the fun linkage between your code and models.
If you just want pretty C4 models, Draw.io is your best bet. But then you lose all the fun linkage between your code and models.
Trying to sign up with GitHub gives me 404 error.
I wasn't able to find information about the company and where it is registered, might want to add that.