Passwords, API keys, tokens, certificates — every team has them, and most teams keep them somewhere they shouldn't. Doriath puts them in the workspace people already log into, encrypted so that not even the administrator can read them. The full recording is above.
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.
Government interfaces are supposed to look and behave a particular way, and building that yourself is a front-end project nobody asked for. NLDesign makes it an install. The full recording is above.
Hermiq skills use the same idea as Claude Code skills: a Markdown document that teaches an agent one capability. If the concept is new to you, part 1 of the Claude Skills series (10 minutes) is a good primer. This series stands on its own, though.
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.
Every skill row in the Hermiq catalog carries a badge of seven dots. In this part you learn what the dots mean, run the Qualify action to earn them mechanically, read the scorecard that explains every failure, and attest level 4 as a human curator. You also learn why the ladder deliberately gets harder to climb from level 5 on.
A skill that "feels right" can still add nothing, or make the agent worse. Paired
evals answer the question with two runs of the same cases: one with the skill, one
without. In this part you use the seeded woo-triage-paired-eval dataset to run a
paired baseline against woo-request-triage, read the delta, and watch the L5
evidence appear where Part 2 left a named gap.
A self-improving skill sounds like a skill that edits itself. In Hermiq it is the
opposite: every improvement is a draft that must survive a content scan, an eval
gate, and your explicit approval before it becomes a new version. In this final part
you read the learnings the seeded tender-summary skill has captured, review its
pending improvement draft, decide it, and learn the version history, rollback, and
republish surfaces that keep the whole loop reversible.
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.
LaunchPad turns the single, fixed Nextcloud dashboard into a set of personal, drag-and-drop workspaces. Every user gets their own dashboards; every dashboard is an independent canvas with its own layout, its own widgets, and its own URL. Admins keep control — roll out templates, restrict widgets per group, and pin a group-wide default — while users still get the freedom to personalise.
This tutorial walks the whole surface end to end, from a first-run dashboard to an admin rollout, using nothing but the UI.
Click the LaunchPad icon in the Nextcloud app launcher, or visit
/apps/launchpad/ directly. The very first time you open it, LaunchPad creates a
personal dashboard for you and seeds it with a starter bundle so you never face
an empty grid.
Two things share the grid, and it's worth knowing the difference from the start:
Open the active dashboard's cog menu (top-right of the workspace) and click Edit dashboard. Resize handles appear on every placement, and each tile and widget grows a small menu button in its corner.
To add a LaunchPad custom widget, open the cog menu again and choose Add custom widget…. The Add Widget modal opens:
For a native Nextcloud widget, the same picker family lets you choose the Nextcloud widget you want (Activity, Recommended files, a widget from any other installed app) — it's proxied onto the grid exactly as in Step 1.
The widget type list only shows a few options. Custom widget types that haven't shipped a configuration form yet are filtered out of the picker — only types you can actually configure appear. Native Nextcloud widgets come from whatever apps are installed and expose a dashboard widget.
Still in edit mode, add a tile for a link you use constantly. Open a tile's menu → Edit tile (or add a new one) and you get:
nldesign app is enabled, the
Custom tab also offers the NL Design government icon set; when it isn't, that
pack is simply hidden rather than showing broken images./apps/files or any external link.Tiles are the fast way to turn a dashboard into a launcher for your team's most -used tools.
The grid is a responsive 12-column layout. In edit mode:
One dashboard per context — a project, a workflow, a role. In the sidebar, click + Add dashboard.
Each dashboard has a stable, friendly URL (/apps/launchpad/<slug>) you can
bookmark or share with a colleague who has access.
When you open /apps/launchpad/ cold, LaunchPad has to pick a dashboard to land
you on. Your personal pin always wins. Open the cog menu on the dashboard you
want and click Set as default — a ★ marker appears next to it in the
sidebar, and that's where LaunchPad opens from now on.
Use the Share button (or the cog menu's Share) to open the sharing surface. Today it shares a dashboard with specific users and groups, each with a permission level — View only, Add only, or Full customization.
Where's the public link? LaunchPad has a public-share API (a tokenised, brute-force-protected read-only link at /apps/launchpad/s/{token}), but the point-and-click control to create one from the UI is still on the roadmap. For now the Share button covers logged-in user/group sharing; public links are minted via the API.
Everything so far was per-user. Now the admin side. Open Settings → Administration → LaunchPad.
The top of the page holds the global defaults — whether users may create personal dashboards, how many they may have, the default permission level, grid columns, and per-dashboard widget limits.
On the Templates tab, click Create template to author a dashboard centrally and assign it to one or more Nextcloud groups. The first time a member of an assigned group opens LaunchPad, they get their own editable copy of the template — a consistent starting layout without locking anyone in. Mark widgets as compulsory in the template and users can't remove them.
On the Roles & Permissions tab you define, per Nextcloud group, an allow-list of widget types. Members of a restricted group see a filtered picker — handy for keeping niche or sensitive widgets out of specific teams, or for reducing choice for non-technical users. An empty list means the full catalogue (the default).
The other tabs round out the admin surface: Group dashboards (one shared dashboard per group, plus the org-wide default set), Sharing (org-wide share defaults and forced-share groups), Operations (health + Prometheus metrics), Versioning & Audit (conditional-visibility rules and privacy-preserving view analytics), and Org navigation (an organisation-wide navigation tree).
Finally, land every user on LaunchPad after login. This one lives in Nextcloud
core, not LaunchPad's own settings: Settings → Administration → Theming →
Navigation bar settings, enable Use custom default app, and put
LaunchPad first in the priority list. Optionally disable the stock
Dashboard app so the two don't compete. LaunchPad registers under the app id
launchpad, which is the value Nextcloud uses everywhere it refers to the app.
The menu tile opens the wrong app. LaunchPad is registered under the folder-derived id launchpad. If a custom navigation entry points at an old mydash.* route it won't resolve — use launchpad.page.index.
You took the fixed Nextcloud dashboard and turned it into a personalised, multi-dashboard workspace: native and custom widgets side by side, shortcut tiles, a second context, a pinned default, and shared access — then, as an admin, rolled a template out to a group, fenced off widgets per group, and made LaunchPad the front door for everyone.
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.
A walk-through of Hydra, Conduction's agentic app factory — the full recording is above. When you're ready to build with it, the hands-on tutorial series takes you from zero to a live Hydra run.
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.
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.
OpenCatalogi is the publishing layer for Conduction apps. Where OpenRegister stores your data and OpenConnector 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.
OpenConnector is the integration engine for Conduction apps. Where OpenRegister stores the data you own, OpenConnector 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 OpenConnector 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.
OpenBuild 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. OpenBuild builds that exact same manifest for you through a UI. You point and click, OpenBuild 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 OpenBuild UI against a real OpenRegister behind it.
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:
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 3 of the Woo tutorial series. Start with Set up Woo and DCAT registers and Upload files to a Woo publication.
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.
In part 5 you started Hydra by hand: build the images, run the supervisor, label an issue. That is the right way to learn Hydra, but it is not how it runs day to day. In production nobody runs hydra-supervisor.sh from a terminal. Instead the forge itself triggers the pipeline when an issue is labelled, pulls pre-built images from a registry, and runs each stage as a CI job. This part explains that path, and the three deployment models behind it.
Most teams already write down what they are going to build. They open a ticket: "As a user I want a search box, so that I can find pets quickly." That sentence has served software teams for twenty years. At Conduction we write specs instead. The reason is simple: the developer reading the ticket is now an LLM, not a colleague, and an LLM needs a different kind of brief. This opener explains why, before the rest of the series gets into the how.
A spec tells you what one feature must do. But "build a search box" leaves a hundred questions unanswered that have nothing to do with search. Which data layer? Vue 2 or Vue 3? Where do modals live? Which licence header? Answering those per spec would be madness, and an AI would answer them differently every time. That is what ADRs are for. They are the standing context that every spec is built on top of. This part explains what they are, how they are written, and how Conduction splits them across the fleet.
In Part 1 you learned that a scenario describes behaviour in GIVEN / WHEN / THEN form. In Part 2 you wrote one. This part closes the loop. A scenario is a test you have not run yet, and OpenSpec gives you a mechanical way to prove that every scenario in a spec is exercised by a real browser test. The @e2e annotation and the gate that enforces it are what turn "write a spec" into a safe sandbox for AI. They are also the single biggest thing that separates spec coding from vibe coding.
Heads up — this is an optional, situational tutorial. Most developers will never need to run a retrofit. Day-to-day work in a Conduction app — writing changes, implementing tasks, opening PRs — doesn't touch any of the commands below. You can finish Parts 1 + 2 and go straight to the Hydra series or the Claude skills series without losing anything.
This part is only relevant in one specific case: an older Conduction app needs to be brought up to date with the current OpenSpec convention after the fact. A small number of our apps were built before openspec/specs/ and the @spec-tag convention existed — they have working code, but no specs and no annotations pointing from code to requirements. If one of those apps ever has to be brought into line with the convention, this is the playbook for it. We work through the retrofit playbook end to end.
By Part 6 your PetStore app is shipped and integrated. Along the way the manifest renderer mounted a handful of nc-vue components for you (CnAppRoot, CnPageRenderer, CnIndexPage, CnDetailPage, CnDashboardPage, CnObjectSidebar, CnMarkdownEditor) and Part 5b walked through the dashboard widget vocabulary. The lib ships ~70 Cn* components and a dozen composables. Part 7 is the capability tour: which component to reach for when, what the composable layer does for you, and how the whole library fits together so you stop guessing.
This is a tour, not a reference. The full prop tables live on nextcloud-vue.conduction.nl. Use Part 7 to build the mental map; use the lib docs to look up signatures.
A 45-minute tutorial that gives your PetStore app a documentation site. Hosted from your own Codeberg or GitHub repo via the central documentation workflow, illustrated with abstract screen mocks that compose from design tokens, and brought to life with real screenshots that Playwright captures from your running app. By the end, every push to development rebuilds and republishes.
A working Conduction workstation needs a specific combination of tools: Claude Code, Docker, Nextcloud running locally, Playwright, a handful of global Claude settings and hooks, and a working gh CLI. New developers often lose their first day (or two) to setup puzzles we've already solved internally. This six-part series gets you from a clean laptop to a working workstation in one evening. Part 1 — this one — answers the question what do you install, and why before you start clicking through installers.
This is the part with the most install commands. WSL2, Docker Desktop, VS Code with the right extensions, the language runtimes (Node, PHP, Composer), the CLIs (gh, OpenSpec), and the Playwright Chromium binary. By the end of Part 2 you'll have a working dev workstation — just without Claude Code wired up yet. That's Part 3.
With the runtimes in place from Part 2, it's time to add the AI pair programmer we actually work with: Claude Code. This part covers the install, the sign-in, and — the bit you should not skip — the mandatory global settings and safety hooks that keep Claude from running destructive shell commands without your approval. Short part, important part.
MCP — Model Context Protocol — is the standard interface Claude Code uses to call out to external tools. Inside a Conduction project, that means two things in practice: a Playwright browser pool (browser-1 … browser-7) for the testing skills, and the OpenRegister MCP server for direct access to your local Conduction data layer. A workstation isn't really complete until at least the browser pool is wired into your project root via .mcp.json. This part covers that; the OpenRegister MCP server has its own tutorial — we link to it at the bottom.
A workstation without a Nextcloud is half a workstation. Nearly every other tutorial in the academy assumes you have one running on localhost:8080. The good news: a dedicated tutorial already covers this end to end. This module is a short bridge that explains why you do it now, which Conduction apps to install once it's up, and how this part connects to the rest of the series.
Your workstation is complete. WSL2, Docker, VS Code with the right extensions, Claude Code with the safety hooks live, the MCP browser pool connected, Nextcloud running locally with the apps you need. Take a moment to feel good about that — most new Conduction developers used to lose one or two days to this; you've done it in one evening. This last part is a short map of the next tutorials, grouped by what kind of work you'll do.
Spec-driven development inverts the usual order. You don't sketch the feature, write the code, then maybe document what you built. You write the specification first — in Markdown, with RFC 2119 keywords and GIVEN/WHEN/THEN scenarios — and an AI agent (Hydra) implements code that satisfies it. The human's job moves up a level: you develop context, not code.
That sounds idealistic until you see it work. Conduction's apps are built this way in production today. This tutorial walks the workflow: what OpenSpec actually is, how ADRs at organisation and app level keep features coherent, what the explore and apply skills do, and how the quality-and-gatekeeping harness validates the result before anything reaches main.
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.
This part deepens the manifest surface. Part 6: Integrate widens the app to other systems (cross-register reads, OpenConnector sources, webhooks). Both build directly on Part 4. Take them in either order, or pick whichever your next app needs first.
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.
Both build directly on the shipped app from Part 4. Part 5: Advanced manifest features deepens the manifest surface (actionToggles, fieldWidgets, public-mode pages). Part 6 widens to other systems. Take them in either order, or pick whichever your next app actually needs first. Neither references the other for content.
The point isn't the specific integrations, it's the pattern. Cross-register reads are how Conduction apps share data without coupling. The OpenConnector 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.
The OpenWoo community meets every second Tuesday of the month. Vendors (Conduction, Xxllnc, OpenGemeenten, SHIFT2, Acato, Notubiz, iO), municipalities in production or acceptance, and KOOP share progress, blockers, and the next slice of the roadmap. Below are all recorded sessions since late 2023.
Part 4 of the nine-part app-building tutorial series. Part 3 made orders appear in NC Calendar with one schema annotation. Part 4 brings external knowledge, category-specific care advice, husbandry notes, feeding tips, from xWiki into the pet detail sidebar via a care_guide OpenRegister schema. Then we package the app and ship it.
External knowledge integration is the canonical case for OpenConnector. Pull data from a system you don't own (xWiki here, but the same applies to Confluence, Notion, SharePoint, Decos, Mendix), surface it inside Nextcloud-native UI without making the user context-switch.
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.
Claude Skills are the mechanism for extending Claude Code with reusable, specialised behaviours. Think of Conduction's own /review-pr, /opsx-new, or the whole hydra-gate-* family: each one is a skill. This first part explains in ten minutes what a skill is, how it gets activated, and when you should not write one. It's part 1 of a four-part track; by the end you'll be ready to write your own in part 2 — and in part 3 we introduce the 7-level maturity framework that takes a skill from "feels good" to "measured good" (part 4 continues with L6 and L7).
In part 1 you saw what a skill is. In this part you'll write one yourself: a working git-status-summary skill that produces a readable summary of the current working tree. At the end it sits in your ~/.claude/skills/ folder, you can invoke it via /git-status-summary, and you'll know how to share it with your team.
You now have a working skill — but does it actually work well? And does it keep working when Claude itself gets upgraded or when you tweak the skill? This third, optional part shows how to evaluate a skill systematically: test scenarios, trigger tests, a baseline measurement, and the eval runner that /skill-creator sets up for you. This is the step from Maturity Level 4 ("feels right") to Level 5 ("measurably right").
In part 3 you took a skill from "feels right" to "measurably right" — Maturity Level 5. For most skills that's enough. But for a handful of skills you use daily, or that steer other skills, you want to go further: a skill that learns from its own executions (L6), and a skill that steers other agents inside a larger workflow (L7). This fourth part shows how you get there — and how the Hydra dashboard lets you monitor your whole skill library for maturity at once.
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.
Haven is een VNG-standaard voor gemeentelijke Kubernetes-clusters. Deze module legt uit wat de standaard voorschrijft, waarom hij bestaat, en hoe je de bouwstenen lokaal nabootst met kind — zodat de term tastbaar wordt voordat je 'm in een aanbesteding tegenkomt.
Hydra runs on OpenSpec changes. If you're not yet familiar with terms like spec, change, requirement and scenario, take the OpenSpec tutorial series first (parts 1 and 2, roughly 30 minutes together). It will save you a lot of backtracking in the rest of these modules.
A large part of Hydra's internals leans on Claude Skills: opsx-*, hydra-gate-*, team-*, test-*. If you've never written or read a skill, take part 1 of the Claude Skills tutorial series first (10 minutes). That makes part 4 of this series — where we open up the skill families inside Hydra — a lot easier to follow.
Hydra is Conduction's internal agentic CI/CD platform: a factory that turns OpenSpec proposals into reviewed, tested code on a feature branch. This module explains in ten minutes what Hydra is, why it exists, and how it fits inside our app factory. It is the first part of a six-part series; by the end you're ready for part 2 on the three pipelines.
In part 1 you saw that Hydra has four personas. In this part we look at the pipeline: how those personas work on one issue one after another, which labels mark the transitions, and when the pipeline diverts to needs-input. By the end you'll know Hydra's label state machine inside out and you'll be able to steer an issue back to the right phase if it gets stuck somewhere.
In part 2 you saw that the three personas are backed up by mechanical quality gates — checks that pass or fail deterministically, without AI in the loop. This part explains which gates we have, why they are mechanical, and how to handle the exception: the false positive.
This part dives straight into the Hydra-specific skill families. If you'd rather first learn what a Claude Skill even is, how the frontmatter works, and when you'd write one yourself, take the public Claude Skills tutorial series (three short modules, ~40 minutes). From here on we assume you know the basics.
The previous parts were about what Hydra does. This part is about how: the skills that let the personas do their job. By the end you'll know which skills the automated pipeline (the "Hydra factory") runs and which ones you call yourself as a human, you'll know the five families, and you'll be able to judge when a new skill is worth writing.
In part 5 the pipeline was running. Now the final part: what do you do when it doesn't go green? This part gives you the decision tree — ordered from cheapest intervention to most expensive — and the patterns that get needs-input issues moving again.
OpenSpec is a lightweight framework for spec-driven development: first write down what a feature should do, only then write the code. In this twelve-minute module you'll learn what OpenSpec is, which concepts it builds on, and why we use it underneath almost every Conduction project. By the end you're ready for Part 2, where you'll actually write your first change.
Want the bigger picture first? For where this idea comes from and why it matters more in an AI world, start with Part 0: Why spec-first. This part dives straight into the concepts.
Your starting point. You don't need to build anything special to follow along. Just clone any Conduction app and read along in its openspec/ folder:
git clone https://codeberg.org/Conduction/openregister.git
cd openregister && git checkout development
ls openspec/ # specs/, changes/, changes/archive/
development is the branch active work happens on. We won't change anything in this part — we're just looking.
The first four parts were about concept, pipelines, gates and skills. Time to actually run. In this part you start a full Hydra run on a target app, paying attention to the practical pitfalls: tokens, images, and — if you work with multiple devs against the same repos — the HYDRA_LABEL_PREFIX trick.
Een Nextcloud-app in de App Store zetten is geen knop, maar een keten. Je hebt een certificaat nodig om je code te signen, dat certificaat krijg je via een pull request op een Nextcloud-repo, en pas met dat certificaat mag je je app registreren en releases uploaden. De officiële documentatie beschrijft elke stap, maar verspreid over vier pagina's. Deze tutorial loopt het in één keer door, van licentiekeuze tot een GitHub Action die elke release automatisch publiceert.
Een Nextcloud opzetten kan op drie manieren, en de "beste" hangt af van wie je bent en wat je al draait. Een homelab op een mini-pc vraagt iets anders dan een gemeente met tien bestuurslagen en een ISO-audit. Deze tutorial zet de drie hoofdopties naast elkaar, met voor- en nadelen en een beslismatrix om snel te kiezen. Niets vervangt de officiële Nextcloud admin docs, maar dit is de korte route naar de juiste hoofdstukken.
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.
Every other tutorial in this academy needs a working Nextcloud. This is the fastest route: a few commands and you run the official Nextcloud locally on your laptop, identical to production. You do not need to be a programmer — if you can install an app and copy and paste text, you will get through this. After that you install the Conduction apps from the Nextcloud app store, the same path as production.
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.
This is the first post on the new Conduction site. We are in active development; the brand book at connext.conduction.nl/identity will be re-homed here once the OpenCatalogi content plugin lands.
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.