CelinQ Insights · No. 88 · Last technically reviewed: August 2026
How to Set Up coArchi for a Team
The mechanics are simpler than they sound; the habits a team builds around them are what actually determine whether it works well.
Short answer. Create an empty Git repository on a server your team already has access to, install coArchi from Archi's Plugins manager, then either clone that empty repository and add your model to it, or add an existing model to it through coArchi's own setup flow. Commit, then publish. The technical setup takes minutes; getting a team's commit-and-publish habits right takes longer.
Before you start: decide where the repository lives
coArchi needs a real Git remote — it does not provide hosting of its own. For most teams this is not a new decision to make from scratch: if the organisation already runs GitHub, GitLab or a self-hosted Git server for software development, the same platform works fine for a model repository, and reusing existing infrastructure is almost always the right call. A team with no existing Git host at all has a genuine, if small, new piece of infrastructure to stand up — a free GitHub or GitLab account is enough to get started, though an organisation with data residency requirements should confirm where that host actually stores data before committing an architecture model to it.
Whoever sets this up needs to create one new, empty repository — resist the temptation to reuse an existing code repository for the model, since coArchi's Grafico format works best as the sole contents of the repository it manages, not mixed in alongside unrelated files.
The setup walkthrough
Install coArchi
From Archi, open Help → Manage Plugins, install coArchi (or coArchi2, the newer rewrite), and restart Archi if prompted.
Create the empty remote repository
On your Git host, create a new, empty repository dedicated to this model. Note its clone URL and set up authentication (an SSH key or an HTTPS access token, depending on your host).
Add or clone into coArchi
Use coArchi's own repository management view to either clone the empty remote (for a brand-new model) or add your existing .archimate file to a new managed repository.
First commit and publish
Commit the model's initial state with a clear message, then publish it. This is the point Grafico actually explodes the model into its per-asset file structure in the remote repository.
Invite the rest of the team
Add collaborators to the remote repository with write access. Each architect installs coArchi locally and clones the now-populated repository into their own Archi.
Once every architect has cloned the repository, day-to-day work looks the same for everyone: model normally, commit locally when it makes sense, refresh and publish to share. The mechanics of that daily cycle, and what actually happens under the hood, are covered in full here.
The habits that actually determine whether it works
The technical steps above are the easy part. What separates a team that gets real value from coArchi from one that finds it "clunky" is mostly a handful of working agreements, not anything coArchi's own UI can enforce:
Small, frequent shares beat large, rare ones
Publishing in small batches through a session shrinks the window in which two people can collide on the same concept, and makes any conflict that does happen easier to reason about.
Pull first, model second
Starting a session by refreshing means you're working against the latest shared state, not a stale local copy that will generate an avoidable conflict later.
The history is only useful if it's readable
coArchi's "Time Machine" history is a real asset — but only if commit messages say what actually changed, the same discipline software teams already expect of themselves.
It is also worth deciding, as a team, roughly who is responsible for which part of the model during a given working period — not because coArchi requires it, but because the fastest way to avoid genuine conflicts is to reduce how often two people are deliberately working the same concept at the same time. When a conflict does happen anyway, here's how to resolve it properly.
An alternative worth knowing about. If your team doesn't already run a Git host, doesn't want to build Git-fluency as a prerequisite for modelling, or is mixing Archi with Sparx Enterprise Architect across the practice, CelinQ's local-first sync is a different answer to the same underlying problem — no Git remote to stand up, no commit-and-publish habit to build. See the full comparison.
Frequently asked questions
Do I need admin rights on a Git server to set up coArchi? You need the ability to create a new, empty repository on whatever Git host the team uses, and to invite collaborators to it. Beyond that, no special privileges are required.
Can we start using coArchi on an existing Archi model? Yes. An existing .archimate file can be added to a fresh Git-backed repository through coArchi's own setup flow; it does not require starting the model from scratch.
Does every architect need their own Git account? Yes, in the same way every developer on a software team needs their own account on whatever Git host is in use — commits and history are attributed per person.
Related reading
How Does coArchi Work?
The Grafico format and commit/publish workflow this setup guide builds toward.