DocumentationChoosing a solution
Compare DAREG, DDRapp and plain Onedata and decide which fits your laboratory.
All three solutions automate moving data from instruments into managed storage. They differ in how data leave the instrument PC, where they are stored, and how much registry and metadata functionality you get on top.
DAREG and Onedata
DAREG uses Onedata as its storage layer, but it is a separate product built on top of it. It adds the dataset registry, metadata templates, experiment tracking and the Lab Client. Using plain Onedata means working with spaces and files directly and building your own ingestion steps.
Side-by-side comparison
| DAREG | DDRapp | Onedata (plain) | |
|---|---|---|---|
| Developed / operated by | CEITEC & NCBR, Masaryk University | CXI, Technical University of Liberec | e-INFRA CZ national service |
| Storage backend | Onedata spaces | S3 (CESNET S3 or any S3-compatible store) | Onedata spaces backed by e-INFRA CZ or your own storage |
| Transfer from instrument PC | Push: DAREG Lab Client desktop app uploads while you measure | Pull: Apache Airflow (DDRflow) fetches over SMB or SFTP; nothing installed on the PC | Your choice: Oneclient mount, storage import, REST API scripts |
| Instrument PC network | Outbound HTTPS to DAREG and Onedata | Private deny-all vLAN supported; only Airflow reaches the PC | Depends on chosen pattern |
| Data organisation | Facility → Collection → Dataset → Experiment | Tenant → Resource (project) → Dataset → Experiment | Space → folders and files |
| Metadata | JSON Schema templates per collection, generated web forms | Metadata schemes per entity; metadata written onto every S3 object; Elasticsearch index | Custom metadata (key-value, JSON, RDF) on files and folders |
| Instrument records | Instruments per facility, device tokens | Instrument registry with logbook, PIDInst metadata | None |
| Search | Structured metadata search in the web UI | Experiment/dataset lists, Elasticsearch/Kibana | Within the file browser |
| Sharing | Owner/Editor/Viewer roles, Onedata share links | Role-based access, presigned links, zip downloads | Space membership, groups, public shares |
| Publication | DOI registration via DataCite | Publish to NRP (InvenioRDM) as draft | Public shares, Open Data with handle services where configured |
| Login | OIDC (institutional / e-INFRA CZ) | e-INFRA CZ AAI | e-INFRA CZ AAI |
| Self-hosting | Yes (Django + Next.js + PostgreSQL) | Yes (Spring Boot + PostgreSQL + Elasticsearch + Airflow) | Use the national service; optionally run your own Oneprovider |
Decision guide
Choose DAREG when
- You run a shared core facility with many instruments and user groups.
- You want metadata templates per instrument or collection, and users filling in structured forms.
- You want data in Onedata, so they can be mounted on HPC or cloud resources and replicated between institutions.
- Operators should control experiments from the instrument PC: start, stop and watch upload progress.
Choose DDRapp when
- Instrument PCs run old or unpatched operating systems and must sit in an isolated network.
- You do not want to install anything on instrument PCs.
- Your storage of choice is S3, for example CESNET S3.
- You want publication to the National Repository Platform (NRP) and integration with your CRIS.
Choose plain Onedata when
- You mainly need reliable storage, sharing and transfer, and a simple scripted or mounted workflow is enough.
- You already have a network storage where instruments write, which can be imported into Onedata.
- You want to build your own ingestion tooling on a national service, using the REST API, Oneclient or OnedataFS.
Not sure yet? Work through the planning checklist and contact the teams listed in Support and contacts.
