Skip to content

Members Portal & Marketplace

start.mdapi.ch is the human front door to the platform: a portal where members see their services and a marketplace where they can request new ones. It is the piece that turns a homelab into a small multi-tenant service provider.

flowchart LR
    member["Member"] --> portal["Portal UI\nstart.mdapi.ch"]
    portal --> resolve["Windmill f/portal\nresolve board / entitlements / health"]
    portal --> req["Marketplace requests\nf/marketplace"]
    req -->|"approval (Pushover tap-links)"| owner["Operator"]
    req --> prov["Provisioning flows\nmailbox · SFTP · subdomain · website · access"]
    prov --> estate["LDAP · mail · DNS · web · storage"]

Portal

The portal renders a per-member board: which services they have, their health, and entry links. It is backed by typed Windmill scripts (f/portal/* — resolve_board, resolve_entitlement, resolve_health) called through scoped tokens; the paths are frozen as a public API surface for the portal frontend. Tiles are entitlement-driven — a member only sees what they hold.

Marketplace

Requests (a mailbox, an SFTP area, a subdomain, a website, access to an existing service) flow through f/marketplace/* scripts:

  • Each request type has a provisioning flow that performs the real work end-to-end — LDAP identity, mailbox + autoconfig, DNS record, web vhost, storage quota — as one transaction.
  • Sensitive request types carry an approval gate: the operator receives a Pushover message with tap-to-approve/deny links (the platform's standard human-in-the-loop pattern), and the flow resumes on the answer.
  • Everything lands in the same estate planes documented elsewhere: mail, DNS, auth/LDAP.

Why it exists

Family-and-friends tenancy with real self-service: the operator approves intents, not tickets — and the provisioning itself is code-reviewed, versioned, and identical every time.