In short
An entity moves around through two mechanisms, and only two: the ZIP archive, which you download and drop back in, and the git repository, which you push to and clone from. The catalog is not a third one: it is a directory of git repositories, and installing an entry amounts to cloning its repository. The gesture is the same for all nine entity types.
Two ways out of Linkr
Every entity — a project, a schema, an ETL pipeline, a plugin — is handled from its card menu, the three dots at the top right. Two entries there lead to two distinct routes, and which one you want depends on what you are doing.
Export
A ZIP file, right now.
To archive a state, email a piece of work, attach an appendix to a paper. A snapshot, with no follow-up.
Versioning
A git repository, over time.
To keep a history, work as a team, publish. You push straight from Linkr — no archive to produce.
Versioning does not go through the ZIP
The Versioning entry opens a window with two tabs, Git repository and Export: two possible ways out in one place, not two steps of one operation. To version, you link the entity to a repository and push — you never download an archive in between.
What is sent is the same either way: the same tree of text files. See Git versioning.
What the archive contains
The ZIP is named after the entity. It is a tree of text files, not an opaque binary format: you can open it, read it, drop it into a repository yourself, attach it to a paper.
Data files stay behind
An export does not contain your data, and that is deliberate: sharing a dashboard must never distribute patient records by accident.
The exclusion covers data file extensions — CSV, Parquet, Excel — and the edit journal that goes with them. A project’s Export tab says as much: “Data files are excluded by default for security. To include a specific dataset, mark it ‘for versioning’ in the Datasets sidebar (right-click).”
That is the whole method: there is no global switch that would carry everything. You mark files one by one — right-click a dataset, Mark for versioning — and a badge then flags those that will travel.
Marking a file also carries its edit journal
Your cell corrections travel with the file, never separately. That is consistent: for a hand-filled collection the original file does not change, and the typed values exist nowhere but that journal.
Connection credentials never leave
No password and no access token appears in an export, and no option can put one there. Hosts, ports, database names, accounts: none of it leaves the machine.
An exported database carries its name and its schema mapping — not a single row of data. Whoever imports it declares their own connection and points it at their own files.
Exporting a whole workspace
A workspace exports in one piece, from its Versioning & export page, Export tab. Checkboxes list the sections to include, each with its description:
| Section | What it carries |
|---|---|
| Projects | The full content: readme, scripts, dashboards, cohorts, concept lists. |
| Wiki | All pages in Markdown, their tree structure and attachments. |
| Plugins | Those authored in the workspace. Built-in plugins are excluded — they come back from the application on import. |
| Schema presets | Your table/column mapping definitions. |
| Databases | Names and schema mappings. Never the connection details. |
| Concept mappings | The full projects: metadata, mappings and source codes. |
| SQL collections | Whole collections, with all their script files. |
| Quality rules | Rule sets and their custom checks. |
| ETL pipelines | Complete pipelines and their files. |
A git-linked entity is not copied into the archive
If an item is linked to a remote repository, the workspace export carries only its metadata and its link — its content stays in its repository. The tooltip says so: “Only metadata and the Git link are exported.”
Exporting that entity on its own, by contrast, includes all of its content. The reduction to a pointer applies to workspace exports only.
Importing
The Import button opens a window with three tabs. The first two are the two mechanisms; the third is a shortcut onto the second, since the catalog points at git repositories.
Upload ZIP
An archive exported from Linkr.
Drag and drop the file, or click to browse. Works in both deployment modes.
From Git
A remote repository, cloned.
URL, branch, and a token if the repository is private. The entity stays linked to the repository.
From the catalog
Content published by other teams.
The catalog, filtered to the type you are importing. Installing clones the entry’s repository: server mode required.
The From Git tab expects three fields: Repository URL, Branch, and Token — the last one only for a private repository. Then Clone & import.
Clone error messages are specific — read them
They distinguish four causes, which saves you looking in the wrong place: repository not found (the URL), branch not found (the branch name), authentication failed (the token), network error (the connection or the proxy).
When the item already exists
This is the everyday situation as soon as several people work together: you re-import an entity you already have. Linkr does not decide for you — an Item already exists window leaves you the choice.
Create copy
Both versions coexist. Pick this to compare, or when you are not sure you want to lose the existing one.
Overwrite
The imported version replaces yours. Pick this when the import is authoritative — you are pulling back a colleague’s reference version.
Re-importing the same entity updates it rather than duplicating it
Every entity carries a lineage identifier that follows it from one installation to another. That is what lets Linkr recognise the same entity coming back modified, rather than a new one. See Entities and sharing.
What the import tells you
An import rarely succeeds in complete silence, and the messages are worth a glance.
- Format issues — the entity is imported, but Linkr found departures from the expected format. The message gives their number. A project produced by an older version, or edited by hand, often goes through this.
- Git-linked items whose content is missing — an imported workspace may contain entities reduced to their pointer, whose repository is private. A panel lists them, you enter an access token, and load each one with a Clone button.
- Imported without its organization — the linked organization could not be created for lack of permission. An administrator adds it, then you link it from the workspace settings.
Importing into a project overwrites its current files
From an existing project’s Import tab, the warning is explicit: “This will overwrite the current project files.” To keep both, import as a new project instead.
What changes between modes
Server mode
All three origins work.
Cloning runs on the server, which gives access to private repositories and to the catalog.
Browser mode
The ZIP works, installing from the catalog does not.
Installing means cloning a git repository, which the browser alone cannot do. You can still browse the catalog.
See Deployment modes to know which one you are running.
Going further
- Community catalog — installing content published by other teams.
- Publishing content — preparing an entity so others can reuse it.
- Git versioning — the git repository, and what leaves a project.
- Entities and sharing — why all nine types export the same way.