Service ideas — candidates for the production cluster
Author: Pierre-André Mudry (with Claude) · Date: August 2026 · Status: idea pool — items leave the page as they ship
Scope: candidate services for the ISC³ production cluster, once the base services of the target architecture (reverse proxy, Keycloak, GitLab, NOC/SOC) are in place. This page is a vetted backlog, not a plan: an idea leaves it either by shipping (todo item, then a service page) or by being dropped with a one-line reason.
Ground rules for any candidate
Every pick from this page inherits the same rules, so they are stated once:
- Ingress through the single reverse proxy, in the
srv-public/srv-internalzones — never a router port-forward. - Authentication brokered by Keycloak (edu-ID) wherever the service speaks OIDC/SAML; throwaway local accounts only where isolation is the point (exams, CTF).
- One disposable container or VM per service, backed up by PBS. A service that needs more operational care than that must name an owner before it is deployed.
- Anything that sends mail depends on the smarthost — check that path works before choosing a mail-dependent service.
- Bus factor 1 is the ceiling: the first wave of user-facing services should stay at three or four. Admin-facing tools are cheaper — no users, no tickets.
- The uplink only lets 80/443 TCP and the VPN UDP port in (catalogue). A candidate that needs any other inbound port is either NetBird-only or not a candidate.
For students
| Service | What it gives | Notes |
|---|---|---|
| Student PaaS — Coolify or Dokku | git push deploys a semester project to *.apps sub-domains behind the proxy. Makes student work publicly visible | Highest teaching value on the list; needs a wildcard DNS entry and per-student quotas |
| Internal LLM — Ollama + Open WebUI | Self-hosted chat assistant, no data leaves campus | Inference on the carnaval A2/T4 today, gpu-01 later; strong visitor demo |
| JupyterHub | Per-student notebooks with GPU kernels, edu-ID login | Serves the data-engineering and AI courses; replaces ad-hoc local installs |
| code-server / Coder | VS Code in the browser, one workspace per student | With the PaaS and JupyterHub, a browser is the only tool a student needs |
| HedgeDoc + PrivateBin + URL shortener | Collaborative markdown, snippet sharing, short links | Three small containers, near-zero maintenance |
| Excalidraw + draw.io | Collaborative whiteboard and diagrams | Static containers, no accounts needed |
| Vikunja or Focalboard | Kanban for semester projects and theses | Keeps student project data off third-party SaaS |
| Jitsi Meet | Self-hosted video calls for remote thesis supervision | Heavier than it looks (TURN, bandwidth) — needs an owner |
| CTFd | Internal CTF competitions for the security major | Scoreboard only on the cluster; vulnerable targets belong in lab-metal, not in production |
| Gophish | Controlled phishing exercises for the security major | Internal targets only; mail-dependent |
| MinIO | Internal S3 for student projects and datasets | Pairs with JupyterHub; the NVMe pool has the room |
| PostgreSQL as-a-service | One managed database per project group | Template LXC + provisioning script rather than a big shared instance |
| MQTT broker + ThingsBoard | IoT backend for the embedded-systems major | Can also ingest the datacenter's own sensors, so it doubles as NOC input |
| Kiwix | Offline Wikipedia / Stack Overflow mirrors | Content to serve inside deliberately air-gapped lab-metal exercises |
| PowerDNS + PowerDNS-Admin | DNS-as-a-service: one delegated zone per student under a teaching domain, with an API | Students run real authoritative DNS and sign it with DNSSEC instead of a lab mock-up. Wants a delegation we control (isc-vs.dev) and a hard cap on zone count |
| MISP + DFIR-IRIS | Threat-intel sharing platform and incident-response case management | Gives the planned SOC (Wazuh, Suricata, Loki) something to do: a blue-team exercise ground rather than dashboards nobody opens. Two stateful services — needs an owner in the security major |
| Kasm Workspaces | Disposable browsers and Linux desktops streamed over 443 | Malware analysis and sacrificial browsing that die with the container; shares the browser-delivery idea with the Exam VDI. Check the Community Edition's concurrent-session limit before committing |
| Label Studio | Dataset annotation for the data-engineering major | The missing step before JupyterHub: students label their own data instead of downloading someone else's |
| eLabFTW | Electronic lab notebook, widespread in academia | Traceable records for embedded/electronics bench work and thesis experiments |
| GlitchTip | Sentry-compatible error tracking for student apps — and for TIS/tMatch in production | Same SDKs as Sentry at a fraction of the footprint; students see their crashes arrive with a stack trace, which is the lesson. Best paired with the PaaS |
| Dependency-Track | SBOM ingestion and supply-chain analysis wired into GitLab CI | Software-engineering plus security in one tool, on a topic every employer now asks about. Needs GitLab first |
| SearXNG | Private metasearch, no tracking | Cheap on its own, but the real reason is that it is the web-search backend Open WebUI plugs into — the internal LLM stops being offline |
| LibreSpeed | Self-hosted speed test against the rack | Network students measure the Wi-Fi, the VPN and the uplink themselves instead of trusting a public test |
| Wakapi + Rallly + Formbricks | WakaTime-compatible coding statistics, Doodle-style scheduling polls, course-feedback surveys | Three small OIDC services with an obvious constituency; Formbricks retires the Google Forms habit |
| Zulip or Matrix/Element | A sovereign programme chat — the official answer to the unofficial Discord | Technically easy, socially not: needs moderation and a migration story before anything is deployed |
| WriteFreely or Ghost | A programme tech blog where semester projects get published | Free showcase for the filière, but public writing needs an editorial owner, not a sysadmin |
Parked until someone owns them: Overleaf CE (collaborative LaTeX for theses), PeerTube (course recordings), Outline (wiki), a game server for student life. None is critical and each is an attack surface plus a support queue.
Dropped on the inbound-port rule: RustDesk (self-hosted remote support) and anything else built
on its own TCP/UDP ports — the uplink drops them, so it would only ever work for clients already on
NetBird, which can reach the machines directly anyway. Stalwart as a teaching mail server
(SMTP/IMAP/DKIM/DMARC in one binary) is tempting for a "build your own mail" lab, but outbound 25 is
filtered upstream and inbound 25 is not open: it can only ever talk to itself inside lab-metal.
Worth it only if a course asks for exactly that.
For admins
| Service | What it gives | Notes |
|---|---|---|
| Snipe-IT | Hardware inventory with serial numbers and assignment | The rack page and the invoices currently disagree on the R630 count — this is the tool for that |
| Semaphore UI (or AWX) | Web UI over the existing Ansible playbooks: runs, logs, schedules | Turns lab-teardown.yml into a button an assistant can click — direct bus-factor relief |
| Apache Guacamole | Browser-based SSH/VNC/RDP bastion to lab machines and iDRACs, with session recording | Same component the Exam VDI proposal is built on — one deployment can serve both |
| step-ca | Internal CA: TLS for mgmt-zone interfaces (PVE, PBS, iDRAC), short-lived SSH certificates for admins | Ends self-signed-certificate warnings on ~30 internal UIs |
| Package caches — apt-cacher-ng, PyPI mirror (the Docker Hub pull-through registry shipped 2026-09-09) | A class or a PXE pool pulling the same images hits the cache, not the shared uplink | Also dodges Docker Hub rate limits; becomes important when the MAAS pool goes live |
| Paperless-ngx | OCR'd, searchable archive for invoices, order confirmations and infrastructure paperwork | Where the EPV confirmation and the ServerShop24 invoices should live |
| Homepage / Homarr | One portal listing every service with its status | Worth adding once the count passes ~10 |
| Renovate self-hosted | A bot that opens merge requests when a dependency in a repo goes stale | Runs as a scheduled CI job on GitLab, so no new guest and no new account store. Also stops student projects rotting between semesters |
| Windmill (or n8n) | Workflow runner for the glue: chained scripts, schedules, webhooks, with a UI and an audit trail | Overlaps Semaphore UI — pick one. Windmill is AGPLv3; n8n's licence is source-available with commercial restrictions, so check it before adopting |
| Plausible CE (or Matomo) | Privacy-friendly traffic statistics for the public sites and the student PaaS apps | Answers the question the marcellus audit could not: which vhosts are still used. No cookie banner needed |
| Ticketing — Zammad or GitLab Service Desk | A queue where a request has a requester, an owner and a state, instead of living in a mail thread | Two options with very different costs — below |
Ticketing — Zammad or GitLab Service Desk
GitLab Service Desk turns an incoming mail address into issues in a project. It is in the free
tier (docs, August 2026), self-managed included, and costs no new guest, no second account store and no second backup
once GitLab is deployed; the requester needs no account. It gives no
agent view, no SLA and no ownership beyond issue assignment. GitLab is still
planned, and Service Desk on a self-managed instance needs GitLab's
incoming-email (mail_room) leg configured.
Zammad (AGPL-3.0, 7.1 in August 2026) is the helpdesk proper: agent views, states, SLAs,
knowledge base, mail/web/phone channels, OIDC against Keycloak. Its docs
ask for 2 cores and 6 GB of RAM at minimum, plus 4 GB if Elasticsearch runs on the same guest
(August 2026) — against the 1–4 GB every other guest here takes. Elasticsearch also wants
vm.max_map_count raised, which an unprivileged container cannot do, so it means a VM or a sysctl on
the rumba host. Its OIDC settings document no claim-to-role mapping (issuer, UID field and scopes
only), so plan on granting agents inside Zammad rather than by group membership as in
NetBox.
The choice is who files the tickets. An internal queue for the admin team: GitLab, once it exists. Requests written in by teachers, the secretariat or students: Zammad, and only then are 6 GB and a second account store worth it.
Both need an inbound mailbox first. srv-mail is outbound only and its
mailer@isc-vs.ch mailbox is shared with the production Moodle, so either option needs a dedicated
pollable mailbox (support@isc-vs.ch at Infomaniak).
Dropped: GLPI, standard as it is in French-speaking schools — its asset half would be a third inventory beside Snipe-IT and NetBox, and its OIDC comes from a plugin, against the Keycloak ground rule above.
Suggested first wave
Admin side first — done: NetBox, Oxidized, Healthchecks and ntfy all shipped 2026-08-16 as one wave. Student side, two services with the best value-per-maintenance: the PaaS and either the internal LLM or JupyterHub, depending on which courses land first.
Shipped 2026-08-21: the utility trio — Stirling-PDF, IT-Tools and CyberChef, the first user-facing wave, three stateless containers with no support queue (service page).
Once the SOC exists, MISP + DFIR-IRIS and per-student PowerDNS zones are the two ideas here that teach something no other school offers — both waiting on an owner in the relevant major, not on hardware.