Workstation Setup tutorial series — Part 5: Run Nextcloud locally
A working Conduction workstation needs a Nextcloud you can test against. That tutorial already exists — this short module frames it as the last install step before you're production-ready, and tells you which apps to install once Nextcloud is up. Fifth of six short modules.
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.
You need a working Nextcloud — here's how
Already have one running on http://localhost:8080? Skip ahead to Clone the Conduction apps into apps-extra. Otherwise pick the route that matches what you'll actually do with it:
Primary — nextcloud-docker-dev + apps-extra/. What most Conduction developers use day-to-day. Clone the upstream nextcloud/nextcloud-docker-dev repo somewhere convenient (e.g. ~/nextcloud-docker-dev), drop the Conduction app repos into its apps-extra/ subfolder (the compose mounts that path into the Nextcloud container at /var/www/html/apps-extra), then from the nextcloud-docker-dev/ root run:
docker compose up nextcloud proxy
Code changes in your cloned app repos show up in the running Nextcloud without rebuilding the image — that's the point of the apps-extra/ mount.
Beginner-friendly demo — Run Nextcloud locally with Docker. A 30-minute walkthrough that pastes a standalone docker-compose.yml into a fresh folder. Aimed at someone who has never used Docker or a terminal. Good for a first run-through; not the layout you'll use day-to-day for actual app development (the standalone compose doesn't have an apps-extra/ mount, so you can't iterate on Conduction app code that way).
Alternative compose with profiles — optional, extra. The Conduction
openregisterrepo also ships its owndocker-compose.ymlwith--profileflags (ai,ui,exapps,solr,ollama,openproject,xwiki,openzaak,openklant, and more) — documented indocs/claude/docker.md. Useful when you need those heavier services, but not required for the workstation chain and not what most Conduction devs run day-to-day. Stick withnextcloud-docker-devfor now.
The rest of this part is the Conduction-dev-flow context — which apps to clone into apps-extra/, and the reset workflow.
Clone the Conduction apps into apps-extra
In the nextcloud-docker-dev flow you don't install Conduction apps from the Nextcloud app store — you git clone them into apps-extra/ so they live on your filesystem and your edits show up in the container.
Inside nextcloud-docker-dev/apps-extra/, clone at minimum:
cd ~/nextcloud-docker-dev/apps-extra
git clone [email protected]:Conduction/openregister.git
git clone [email protected]:Conduction/openconnector.git
- OpenRegister — the schema-backed object store every Conduction app reads and writes through. Without it, nothing else works.
- OpenConnector — the integration layer for inbound and outbound flows (forms, webhooks, sync, periodic jobs).
A third app shows up in many tutorials — clone when you need it:
git clone [email protected]:Conduction/opencatalogi.git
- OpenCatalogi — makes every register searchable as a public catalogue and federates to
data.overheid.nl.
After cloning and running docker compose up nextcloud proxy, enable each app inside the running Nextcloud — either through the admin UI's Apps page (under Your apps → Disabled apps) or with occ app:enable <appid> against the Nextcloud container.
A note on naming: OpenWoo is a solution built on OpenRegister and OpenCatalogi, not a separate Nextcloud app or repo — there's no Conduction/openwoo to clone. The Woo tutorials use OpenRegister (and usually OpenCatalogi) and import a Woo register into them.
You don't need to clone every Conduction app. Clone what the tutorial you're following asks for and ignore the rest until you need it.
Did the canonical tutorial first? The Run Nextcloud locally with Docker tutorial installs OpenRegister, OpenCatalogi, and OpenConnector from the Nextcloud app store. That works for reading and demos, but the installed apps are immutable production builds — not your local code. Switch to the
apps-extra/flow before you start writing app code.
Fresh install or keep the existing one?
A question that comes up a lot once you've used the local Nextcloud for a while:
- Keep it when continuing on the same change. Schemas you imported yesterday, test objects you created — all still there. Most of the time you keep it.
- Reset it when a tutorial says "start from a clean Nextcloud". That's almost always the case for the Build an App tutorial series, and for any tutorial that imports schemas from scratch.
To reset, run from your nextcloud-docker-dev/ directory:
docker compose down -v
docker compose up nextcloud proxy
-v removes the volumes, so all Nextcloud state — admin account, app config, registers, files — goes with it. The images stay cached so the next start is fast.
Later —
clean-envskill from Hydra. Once you have thehydrarepo cloned (later in the academy chain, not now), theclean-envClaude skill wraps the reset + re-enables the core Conduction apps in one step. Optional and extra; the plaindocker compose down -vabove is all this tutorial needs.
The cleanup is fast — not a slow Windows-style "uninstall and reinstall". Don't be precious about your local state.
How this fits in the workstation chain
A quick recap before Part 6:
- Part 1 — what you install, and why.
- Part 2 — runtimes and CLIs (WSL2, Docker, Node, PHP,
gh, OpenSpec, Playwright). - Part 3 — Claude Code and the mandatory safety hooks.
- Part 4 — MCP browser pool so Claude can drive a browser for testing.
- Part 5 — Nextcloud so there's something to drive against.
- Part 6 — what now? — a map of the next tutorials.
After this part your workstation is complete. The tools are installed, Claude is wired up with safety, the browsers can drive the UI, and Nextcloud is running with the apps you need. Part 6 is the lap of honour.
Test yourself
Four short questions to check that this part landed. Stuck? Click Hint. Curious about the answer? Click Answer.
1. Why is Nextcloud locally the last install step rather than an earlier one?
Hint
It's not about installation order being arbitrary — it's about what each earlier part gives you.
Answer
Because the earlier parts deliver the toolchain — Docker (Part 2), Claude Code (Part 3), the browser pool (Part 4) — that you need to use the local Nextcloud productively. Installing Nextcloud first would give you a working server with no AI assistant, no automated tests, and no easy way to inspect it from VS Code.
By the time you reach Part 5, every other tool is in place. Bringing up Nextcloud is the moment your workstation starts to feel like a workstation, not a pile of installers.
2. OpenRegister and OpenConnector are the two apps you start with. What kind of Conduction work could you do with only OpenRegister — and what would you suddenly be unable to do without OpenConnector?
Hint
OpenRegister is the schema-backed object store. OpenConnector is the integration layer. Think about which of those a typical Conduction tutorial actually touches.
Answer
With only OpenRegister, you can:
- Create registers and define schemas (the what does this data look like layer).
- Create, update, and query objects via OpenRegister's API.
- Attach files to objects (the Upload files to a Woo publication tutorial only needs OpenRegister).
Without OpenConnector, you can't:
- Receive data from an external source (forms, webhooks, scheduled imports).
- Push data out to PLOOI, an open-overheid.nl endpoint, or any external system.
- Build any tutorial that uses a public form → Conduction app flow (Build an App tutorial needs OpenConnector for the public-form step).
The shorter version: OpenRegister stores; OpenConnector moves. If the tutorial only reads/writes data inside Nextcloud, OpenRegister alone is enough. As soon as data crosses the boundary, you need OpenConnector.
3. When do you reset the local Nextcloud, and when do you keep the existing state?
Hint
The two answers map cleanly: same change → keep, new tutorial demanding a clean state → reset.
Answer
- Keep it when continuing on the same change. Yesterday's schemas, test objects, and config are still in the volumes — and you usually want them.
- Reset it when a tutorial says "start from a clean Nextcloud". The Build an App tutorial series usually does. Reset with
docker compose down -v && docker compose up nextcloud proxyfrom yournextcloud-docker-dev/directory — about 30 seconds.
The reset is cheap. Don't hesitate to use it when the tutorial calls for it; trying to "make do" with a dirty environment costs more time than the reset itself.
4. You stopped halfway through Build an App tutorial Part 3 yesterday — your local Nextcloud has a half-built PetStore calendar app and a register full of test pets and orders. Today you're starting fresh on the Set up a Woo register tutorial. Do you reset Nextcloud first, or keep it as-is?
Hint
Which of the two tutorials assumes a clean Nextcloud? And what's the cost of not resetting if it does?
Answer
Reset. The Woo register tutorial assumes a clean Nextcloud — it imports the canonical Woo TOOI schemas into OpenRegister. The PetStore schemas (pet, category, order) and the test data from Part 3 don't strictly collide with Woo, but yesterday's clutter sits in the same OpenRegister UI and you'll be scrolling past it every time. Cleaner to start fresh.
The reset is cheap: docker compose down -v (from your nextcloud-docker-dev/ directory) drops the volumes, then docker compose up nextcloud proxy brings it back up — about 30 seconds total. Yesterday's state is gone, but yesterday's state was a half-finished exercise you weren't going to resume mid-tutorial anyway.
The reverse case — you stopped halfway through Build an App tutorial Part 3 yesterday and are continuing with Part 4 today — is when you keep the state. Your in-progress register is still there and you'd lose 20 minutes recreating it.
The rule of thumb: same tutorial → keep, different tutorial → reset.
Next step
Your workstation is complete. Time for the lap of honour — what you do next now that you can actually build.