CelinQ Insights · No. 84 · Last technically reviewed: August 2026

How Does coArchi Work? A Technical Look at Archi's Git Collaboration Plugin

coArchi is the real, purpose-built answer to "how do I share an Archi model with a team" — this is what it actually does under the hood, not the marketing summary of it.

What coArchi actually is

coArchi — formally the archi-modelrepository-plugin, with a newer rewrite called coArchi2 in progress — is Archi's own official collaboration plugin, built and maintained by the same community behind Archi itself. It is not a third-party workaround bolted onto a tool that never expected to be shared; it is the ecosystem's purpose-built answer to exactly that gap, installed like any other Archi plugin through Archi's own Plugins manager.

What it adds is a Git-backed repository model, but a specific kind of one. A team creates an empty Git repository on a server they already run or already use — GitHub, GitLab, Bitbucket, or a self-hosted instance — and coArchi manages the connection between that remote repository and a local working copy of the model, entirely from inside Archi's interface. You do not need a separate Git client, and you do not need your architects to already know Git commands, though understanding roughly what a commit and a push do will make the experience considerably less confusing the first time something goes wrong.

The part that actually makes Git work for a model: Grafico

The detail that matters most, and the one a lot of high-level descriptions skip past, is what coArchi actually commits to Git. A raw .archimate file is a single XML document describing the entire model — every element, every relationship, every diagram, every property — serialised as one large, deeply nested block of markup. Handing a file like that to Git is technically possible but practically useless: two architects each renaming a different, unrelated element will typically still produce a file-level conflict, because Git's line-based diff has no idea that one change was ten thousand lines away from the other inside the same monolithic document.

coArchi avoids that problem by never committing the single file at all. It uses a format the project calls Grafico, which explodes the model into a real folder-and-file hierarchy: separate subfolders roughly by asset type — application, business, technology, diagrams, relations, and so on — with one small, individually named XML file per model object inside each. Because each file is small, human-readable, and scoped to one concept, two architects editing two different elements almost always end up touching two different files, which Git can merge automatically without any human intervention at all. It is not a clever hack layered on top of Git; it is the specific design decision that makes Git collaboration on an ArchiMate model realistic in the first place, rather than a source of constant, spurious conflicts.

The daily workflow: commit, then publish

Day to day, an architect works in Archi exactly as they always have — nothing about modelling itself changes. coArchi's own vocabulary keeps commit and share as two distinct, deliberate steps rather than one action, which matters for how the workflow actually feels:

That two-step shape — commit locally, then separately choose to publish — is deliberate and worth understanding on its own terms, not just as "Git with different button labels." It means an architect can checkpoint their own work-in-progress repeatedly through a session, entirely offline, without ever exposing half-finished thinking to the rest of the team, and only decide to publish once a piece of work is actually ready to share. That is a genuine, useful property, and it is one CelinQ's own local-first approach shares in spirit, even though the mechanism underneath is completely different — a companion service exchanging changes with a server rather than an explicit commit-and-publish action a person triggers.

What happens when two people change the same thing

Because of Grafico's file-per-asset split, most concurrent changes across a team never produce a conflict at all — two architects working on different elements are, from Git's point of view, editing different files, and Publish simply combines both sets of changes automatically. A genuine conflict only surfaces when two people change the same concept — the same element, the same relationship, the same diagram — before either one has published. When that happens, coArchi presents a conflict dialog inside Archi itself rather than dropping an architect into a raw text merge tool full of Git conflict markers, and the resolution happens in the context of the model, not a diff of two versions of an XML fragment. It is a real, usable answer to the conflict problem — but the choice it is asking a person to make is still, underneath, "which version of this file wins," not an automatic judgement about whether the two changes are actually compatible and could both be kept. Two architects who each add an unrelated property to the same element, in a way a human would obviously consider non-conflicting, can still be asked to resolve it as a conflict, because Git's merge machinery reasons about file regions, not ArchiMate semantics.

coArchi also keeps a full commit history — its own documentation calls this the model's "Time Machine" — so a team gets real, browsable versioning of who changed what and when, the same guarantee any Git-backed workflow gives you for source code. More recent versions add proper branch creation, deletion and merging directly from Archi's own UI, extending the same familiar Git concepts — a feature branch for a piece of exploratory modelling, merged back once it is settled — into architecture modelling rather than leaving branching as something only available to teams willing to drop into a terminal.

What a team actually signs up for

None of this is free, and it would be unfair to describe coArchi as a magic fix without naming the real cost. Someone has to stand up and maintain the remote Git repository — genuinely trivial if the team already runs GitHub or GitLab for everything else, a real piece of new infrastructure if it doesn't. Architects have to build the habit of committing and publishing at sensible points in a working session, a discipline software teams already have baked in but a modelling practice does not necessarily start with. And even with coArchi's own UI standing between an architect and raw Git commands, the underlying mental model is still fundamentally Git's — branches, commits, conflicts, a remote you have to stay in sync with — which one honest, hands-on account of using it describes as feeling "a little clunky if you're already familiar with git," a fair characterisation of a UI that has to represent genuinely complex operations without hiding what's actually happening underneath.

Frequently asked questions

Related reading