43 posts tagged with "OpenRegister"

Buildiq is a Nextcloud app built on OpenRegister. Reading about what it does is not the same as clicking through it, and standing up a Nextcloud by hand to find out is more work than most people will do on a first look.

This tutorial removes that step. One file, two commands, and you are looking at the real thing.

Decidiq is a Nextcloud app built on OpenRegister. Reading about what it does is not the same as clicking through it, and standing up a Nextcloud by hand to find out is more work than most people will do on a first look.

This tutorial removes that step. One file, two commands, and you are looking at the real thing.

Dossiq is a Nextcloud app built on OpenRegister. Reading about what it does is not the same as clicking through it, and standing up a Nextcloud by hand to find out is more work than most people will do on a first look.

This tutorial removes that step. One file, two commands, and you are looking at the real thing.

Filinq is a Nextcloud app built on OpenRegister. Reading about what it does is not the same as clicking through it, and standing up a Nextcloud by hand to find out is more work than most people will do on a first look.

This tutorial removes that step. One file, two commands, and you are looking at the real thing.

Hermiq is a Nextcloud app built on OpenRegister. Reading about what it does is not the same as clicking through it, and standing up a Nextcloud by hand to find out is more work than most people will do on a first look.

This tutorial removes that step. One file, two commands, and you are looking at the real thing.

Humaniq is a Nextcloud app built on OpenRegister. Reading about what it does is not the same as clicking through it, and standing up a Nextcloud by hand to find out is more work than most people will do on a first look.

This tutorial removes that step. One file, two commands, and you are looking at the real thing.

Integriq is a Nextcloud app built on OpenRegister. Reading about what it does is not the same as clicking through it, and standing up a Nextcloud by hand to find out is more work than most people will do on a first look.

This tutorial removes that step. One file, two commands, and you are looking at the real thing.

Keepiq is a Nextcloud app built on OpenRegister. Reading about what it does is not the same as clicking through it, and standing up a Nextcloud by hand to find out is more work than most people will do on a first look.

This tutorial removes that step. One file, two commands, and you are looking at the real thing.

Larpinq is a Nextcloud app built on OpenRegister. Reading about what it does is not the same as clicking through it, and standing up a Nextcloud by hand to find out is more work than most people will do on a first look.

This tutorial removes that step. One file, two commands, and you are looking at the real thing.

Launchpad is a Nextcloud app built on OpenRegister. Reading about what it does is not the same as clicking through it, and standing up a Nextcloud by hand to find out is more work than most people will do on a first look.

This tutorial removes that step. One file, two commands, and you are looking at the real thing.

Learniq is a Nextcloud app built on OpenRegister. Reading about what it does is not the same as clicking through it, and standing up a Nextcloud by hand to find out is more work than most people will do on a first look.

This tutorial removes that step. One file, two commands, and you are looking at the real thing.

OpenCatalogi is a Nextcloud app built on OpenRegister. Reading about what it does is not the same as clicking through it, and standing up a Nextcloud by hand to find out is more work than most people will do on a first look.

This tutorial removes that step. One file, two commands, and you are looking at the real thing.

OpenRegister is a Nextcloud app built on OpenRegister. Reading about what it does is not the same as clicking through it, and standing up a Nextcloud by hand to find out is more work than most people will do on a first look.

This tutorial removes that step. One file, two commands, and you are looking at the real thing.

Pipelinq is a Nextcloud app built on OpenRegister. Reading about what it does is not the same as clicking through it, and standing up a Nextcloud by hand to find out is more work than most people will do on a first look.

This tutorial removes that step. One file, two commands, and you are looking at the real thing.

Planninq is a Nextcloud app built on OpenRegister. Reading about what it does is not the same as clicking through it, and standing up a Nextcloud by hand to find out is more work than most people will do on a first look.

This tutorial removes that step. One file, two commands, and you are looking at the real thing.

Portaliq is a Nextcloud app built on OpenRegister. Reading about what it does is not the same as clicking through it, and standing up a Nextcloud by hand to find out is more work than most people will do on a first look.

This tutorial removes that step. One file, two commands, and you are looking at the real thing.

Shillinq is a Nextcloud app built on OpenRegister. Reading about what it does is not the same as clicking through it, and standing up a Nextcloud by hand to find out is more work than most people will do on a first look.

This tutorial removes that step. One file, two commands, and you are looking at the real thing.

Stackiq is a Nextcloud app built on OpenRegister. Reading about what it does is not the same as clicking through it, and standing up a Nextcloud by hand to find out is more work than most people will do on a first look.

This tutorial removes that step. One file, two commands, and you are looking at the real thing.

Thematiq is a Nextcloud app built on OpenRegister. Reading about what it does is not the same as clicking through it, and standing up a Nextcloud by hand to find out is more work than most people will do on a first look.

This tutorial removes that step. One file, two commands, and you are looking at the real thing.

Versioniq is a Nextcloud app built on OpenRegister. Reading about what it does is not the same as clicking through it, and standing up a Nextcloud by hand to find out is more work than most people will do on a first look.

This tutorial removes that step. One file, two commands, and you are looking at the real thing.

Zaakafhandelapp is a Nextcloud app built on OpenRegister. Reading about what it does is not the same as clicking through it, and standing up a Nextcloud by hand to find out is more work than most people will do on a first look.

This tutorial removes that step. One file, two commands, and you are looking at the real thing.

Connext is not one app. It is a registry (OpenRegister) with a set of applications built on top of it, and the interesting behaviour lives in how they fit together — a catalogue that publishes, a portal that renders it, a connector that feeds it. Reading about that is not the same as clicking through it.

This tutorial gets the whole thing running locally so you can click through it.

This is a demo environment, not a development environment. It runs the real software and behaves the same way, so what you learn here applies to a production deployment. But nothing here is backed up, and docker compose down -v permanently deletes all of it. Explore freely; do not put real data in it.

Step 1: Check your Docker version​

docker compose version

You need v2.23 or newer. If it prints something older, upgrade before continuing.

This matters more than a version check usually does. The compose file declares its install scripts inline, using a Compose feature older versions do not have — and they do not complain about it. They ignore the field, start Nextcloud with no applications installed, and give you an empty instance with nothing in the logs to explain why.

Step 2: Download the compose file​

curl -fsSLO https://www.conduction.nl/connext/connext-compose.yml

One self-contained file. There is nothing else to fetch, and nothing to edit.

Step 3: Start the stack​

docker compose -f connext-compose.yml up -d

The first run takes several minutes. It pulls three images, then downloads and unpacks eleven application archives before Nextcloud starts at all.

Watch the install if you like:

docker compose -f connext-compose.yml logs -f app-installer

You are looking for a line naming each app, and then this:

==> apps present: filinq hermiq integriq launchpad opencatalogi openregister
    pipelinq portaliq shillinq thematiq zaakafhandelapp

Nextcloud then installs itself and enables the apps in dependency order — OpenRegister first, because every other app declares its registers and schemas against it, and a leaf app enabled before it finds no register to attach to.

The stack is ready when this returns "installed":true:

curl -s http://localhost:8700/status.php

Step 4: Open it​

Start with the portal. It is public — no login — and that is the point: it is what a citizen would see. Signing in as admin shows you a different and more permissive view.

Why the portal needs ?portal=demo​

One instance can host several portals, and Portaliq resolves which to serve in exactly two ways: an explicit ?portal=<slug>, or a request hostname matching a portal's verified domain.

There is deliberately no third mode and no default-portal fallback. A default is precisely how a multi-tenant host ends up serving one tenant's content under another tenant's domain. The seeded demo portal ships with no domains at all, because an install hook has no business claiming a hostname on your behalf — so the slug parameter is how you reach it.

On a throwaway box you can bind localhost yourself under Portaliq → Portals → demo → Domains, mark it verified, and then drop the parameter.

Step 5: Check that it actually worked​

This is the step people skip, and it is the one worth doing.

A page loading is not a page working. Nextcloud serves its page shell before an app decides whether it has anything to render, so the portal URL returns HTTP 200 even when it resolves to nothing at all. A smoke test that checks for a 200 would call that a success.

So check content instead:

# Should name the portal — not answer {"error":"not_found"}
curl -s "http://localhost:8700/apps/portaliq/api/content/site?portal=demo"

# Should list at least one catalog — not {"results":[],"total":0}
curl -s "http://localhost:8700/apps/opencatalogi/api/directory"

The second one deserves a note. An empty directory does not mean "no federation peers" — it means the register configuration was never imported. Those two states are indistinguishable from the outside, and one of them is a broken install. That ambiguity is exactly why the check is worth running rather than trusting the absence of an error.

Pinning versions​

By default each app resolves to its newest release, pre-releases included, because most Connext apps do not yet publish a stable one. That is honest about what exists, but it is not reproducible.

Pin whatever you need:

OPENREGISTER_VERSION=1.1.6 \
OPENCATALOGI_VERSION=1.0.9 \
CONNEXT_PORT=9000 \
docker compose -f connext-compose.yml up -d

Removing it​

# Stop, keep the data
docker compose -f connext-compose.yml down

# Stop and delete everything, including the database
docker compose -f connext-compose.yml down -v

Why nothing is mounted from a checkout​

You may notice this compose file downloads release archives rather than pointing at repositories, and that no volume maps to a directory on your machine. Both are deliberate.

Nextcloud installs and updates an app by deleting the app directory and extracting a fresh archive over it. Point that at a git checkout and an app-store update will delete your working tree — we measured exactly that on a development machine in August 2026: an updater fired on a container restart and removed every top-level file from a bind-mounted checkout, including its .git directory.

There is a second reason, and it is the one that bites quietly. A release archive is a complete application: it carries its vendor/ directory and its built JavaScript. A git clone carries neither — and a Nextcloud app with no vendor/ does not fail loudly. It warns once and keeps loading, so the app appears installed while every service that needs a dependency is silently missing.

To work on these apps rather than with them, you want a development environment instead. This file cannot serve that purpose and does not try.

Most agent platforms ask you to ship your data somewhere else. Hermiq runs the agents inside the Nextcloud you already operate — agents, their memory and their skills all stored as OpenRegister objects, governed and audited like anything else on the instance. The full recording is above.

A Hermiq agent gets new capabilities through skills: Markdown documents in the open agentskills.io format, stored as OpenRegister objects. In this part you browse the skills catalog, read the anatomy of the seeded example skills, install one onto an agent, and author your own skill twice: once by hand in the markdown form, once in conversation with the seeded skill-creator skill.

Nine minutes. One app. No code. The recording sits above.

You model the data. You compose the pages. You ship to the app store. You never leave the browser.

Shillinq is an open-source business-administration app for the Nextcloud workspace. It covers double-entry bookkeeping, sales and purchase invoicing, procurement, contract management, and bank reconciliation, all on top of OpenRegister. This first tutorial keeps it small: you install the app, get your bearings on the Financial overview dashboard, and create your first sales invoice with the quick draft. Everything happens in the browser, no configuration files.

How a single manifest turns into a running app — the full recording is above. To build one yourself, the Build-an-app series walks the manifest from first schema to shipped app.

Building and shipping an app in the browser, no code required — the full recording is above. The hands-on tutorial walks the same build step by step so you can follow along.

Integriq is the integration engine for Conduction apps. Where OpenRegister stores the data you own, Integriq reaches out to data you do not — a case-management API, an open-data portal, a partner's REST service — and pulls it into a register on a schedule, reshaped to fit your own schema. It does this without a line of integration code: you describe where the data lives, how a record should be reshaped, and what should run, and Integriq does the fetching, the transforming, the writing and the deduplicating for you.

This tutorial fills the Pet Store register you built in Part 1 from a real, public, external API — the Swagger Pet Store. You register that API as a source, test it, write a Twig mapping that turns an external pet into a pet-academy object and test the mapping against a sample record, build a synchronisation that ties it all together, run it for real to create pets in your register, and schedule it so it keeps the register current. No code, no cron file, no glue.

OpenCatalogi is the publishing layer for Conduction apps. Where OpenRegister stores your data and Integriq fills it from elsewhere, OpenCatalogi turns a register you own into a public, browsable, harvestable catalog: a set of API endpoints that anyone on the internet can read, and a DCAT-AP-NL feed that national portals like data.overheid.nl and data.europa.eu can harvest. It does this without a "publish" button and without copying your data anywhere — publishing is a rule on the data, enforced by OpenRegister, and a catalog is just a filter that says which data belongs in the shop window.

This tutorial takes the Pet Store register you built in the first two parts and makes it public. You scope a catalog to the register, set up the visibility rule, publish nine pets while deliberately keeping one hidden, prove the rule from a logged-out browser, and expose the whole thing as a DCAT-AP-NL feed. No code, no second server, no export.

OpenRegister is the data engine behind every Conduction app. It stores your data not as rows in a hand-built table but as objects that follow a schema you design, grouped into a register you own. Where a traditional application bakes its data model into code and a database migration, OpenRegister lets you draw the model in the interface and start storing real records the same minute, with versioning, an audit trail, search, files and permissions all handled for you.

This tutorial builds a Pet Store data model, the canonical Conduction sample domain. You will create a register, design a pet schema, add owner and category schemas with real relations between them, fill the register with pets through the interface, attach a photo to one, make pets findable in Nextcloud's search, and finally export the whole thing as a configuration file that travels to any other instance. No code, no database, no deploy.

Buildiq is the visual builder for Conduction apps. The three-paths tutorial teaches the manifest path by hand: you write manifest.json and the Cn* components render it. Buildiq builds that exact same manifest for you through a UI. You point and click, Buildiq writes the manifest and the OpenRegister schemas behind it, and you get a working Nextcloud app with no repository, no build step, and no deploy.

This tutorial builds a Pet Store with a veterinary layer, the canonical Conduction sample domain. By the end you have an app your whole organisation can open: a dashboard of live numbers and charts, browsable lists of pets and owners, a rich pet profile page, a vets-only medical section, a released production version, a widget on everyone's LaunchPad, vet appointments in Nextcloud Calendar, and photos attached to each pet. Everything in this tutorial is built in the Buildiq UI against a real OpenRegister behind it.

In Part 1 you imported a DCAT register for open data. In this tutorial you make its datasets findable: you scope a catalog to the register, set one date field that controls visibility, and expose the catalog as a DCAT-AP-NL feed. National portals like data.overheid.nl harvest that feed.

The first three parts of this series set up the registers, the files, and a public catalog for Dutch open-government data. Conduction also has a three-tutorial pipeline that teaches the same three apps from the ground up, end to end, on the canonical Pet Store sample:

1. Model and manage your data with OpenRegister — registers, schemas, relations, objects, search, versioning, permissions.
2. Pull external data into your register with Integriq — a source, a mapping, and a scheduled synchronisation.
3. Publish a public catalog with OpenCatalogi — scope a catalog, publish with a date rule, expose a DCAT-AP-NL feed.

This capstone is the Woo & DCAT overlay on that pipeline. Rather than repeat the mechanics, it points you at each deep tutorial and then layers the open-government specifics on top: the canonical registers you import instead of hand-building, the open-data source you map to a Dataset, and the DCAT-AP-NL feed that national portals harvest. The shape is identical to the Pet Store chain — grab data from a source, and publish it on a catalog — only the domain changes.

This is Part 5 of the nine-part app-building tutorial series. Parts 1–4 got you a working app: scaffold, schemas + manifest, schema-driven Calendar integration, and a custom Care tab. Part 5 is the "now what": the v2.7.0 manifest features Parts 1–4 deliberately skipped so the learning curve stayed gentle. You don't need any of them to ship PetStore, but the moment your app needs a public form, a wiki, an admin-only listing, or a markdown editor inside a form, they save you from another round of hand-rolled Vue.

Three principles run through every feature in this part: schema-driven (no per-page Vue), type-safe (the manifest schema validates every shape before runtime), and fleet-portable (the same JSON works in every Conduction app and gets lib upgrades for free).

This is Part 6 of the nine-part app-building tutorial series. Part 4 packaged the app and put it on the Conduction store; this part makes it talk to the rest of the workspace: three integration patterns layered from least to most invasive. By the end your orders know who their supplier is, every order shows the right care guide from xWiki, and a needs_followup order automatically opens a maintenance page in xWiki that flips the order back to delivered when the page is marked resolved.

The point isn't the specific integrations, it's the pattern. Cross-register reads are how Conduction apps share data without coupling. The Integriq source-and-synchronisation pattern is how you absorb data from anywhere into your own register. The webhook endpoint pattern is how external systems push state back. Once you've wired all three, you've covered the integration vocabulary the rest of the catalogue uses.

This is Part 3 of the nine-part app-building tutorial series. Part 2 wired the pet and order schemas. Part 3 makes those orders appear in every user's Nextcloud Calendar (without writing a controller, an event listener, or any per-app calendar glue).

The trick: OpenRegister already ships an ICalendarProvider (RegisterCalendarProvider) that exposes any schema with a calendarProvider block as a virtual calendar. You declare the block on the order schema. NC Calendar shows the events. That's the whole story.

This is Part 2 of the nine-part app-building tutorial series. Part 1 left you with an empty app shell, a chassis, no data. Part 2 fills the chassis: three schemas (modelled on the OpenAPI Pet Store), a manifest, and the same five Cn* pages drive every list, every detail view, every dashboard with the schema as the single source of truth.

The shape we keep saying "this saves you code" finally has numbers behind it: ~200 lines of hand-rolled Vue collapse to three.

This is Part 1 of the app-building tutorial series, the hands-on chassis lap. If you haven't read Part 0: Three paths, one curriculum yet, that's the orientation that explains why we build on this stack rather than raw Nextcloud, and how the manifest and @conduction/nextcloud-vue work as two intertwined surfaces. Part 1 picks up after that decision is made.

You'll build PetStore, a Nextcloud app on top of the OpenAPI Pet Store domain (pets, orders, categories, tags) on the full Conduction Nextcloud stack. The end product: add pets to the store, place orders, see order ship-dates in your Nextcloud Calendar, and surface category-specific care guides from xWiki right next to each pet. Every piece reuses what @conduction/nextcloud-vue and OpenRegister already give you for free.

In Part 1 you scaffold the app, rename it, build it, and see the canonical app chassis on screen. No data, no integrations yet. We get the bones right first.

A Woo publication without files is metadata without evidence. In this tutorial you attach documents to a publication through the OpenRegister interface, choose which ones are public, and remove them again. An appendix covers the API, for scripts and for files too large for a browser upload.

The Dutch Open Government Act (Woo) asks government bodies to publish documents in set information categories. Open data is published as datasets in the DCAT-AP-NL standard. OpenRegister stores both. In this tutorial you import two registers, the Woo register and a DCAT register, using only the OpenRegister interface.

This is Part 0 of the nine-part app-building tutorial series, the orientation lap. Before scaffolds, schemas, or manifests, the most useful thing we can hand a new developer is an honest map of the three ways Conduction apps actually get built, what each one costs, and what each one gives back. The rest of the series picks one path and shows the receipts. Part 0 explains why.

A second thing matters from minute one: the manifest system and the @conduction/nextcloud-vue component library are two different surfaces. The manifest is the declarative what, a single manifest.json that describes navigation, pages, configuration. nextcloud-vue is the rendering how, the Cn* components the manifest dispatches to (CnAppRoot, CnPageRenderer, CnIndexPage, CnDetailPage, CnDashboardPage, and the rest). They are technically separable. They are also so intertwined in practice that the rest of this series teaches them together, and every lesson names which surface it is touching.

The series uses the OpenAPI Pet Store as the running example: pets, orders, categories, the same entities every API developer has met before. It's the canonical sample domain across the Conduction academy. By the end of the series you have a working PetStore app on the Conduction stack and the mental model to build your own real app on the same patterns.

The OpenRegister Nextcloud app exposes an MCP server at /index.php/apps/openregister/api/mcp. Once you point Claude at it, you can ask questions like "list every schema in the woo register" or "give me the audit trail for object X" and Claude will fetch the answer through MCP instead of you opening the admin UI. This tutorial assumes you already have a local Nextcloud with OpenRegister running and a Playwright .mcp.json in place — what we add here is one more entry to that file, plus the Nextcloud app-password that makes the call work.