Platform Architecture

1 Button Deploy

From zero to a fully operational client environment in a single click. Every client gets a completely separate environment — their own database, their own Workers, their own DNS — not a shared tenancy with feature flags.

Mio platform stack - Lucca Mocca Panna

The Three Layers

Mio's deployment architecture is built on three distinct layers, each with a clear responsibility, keeping infrastructure, platform code, and client environments strictly separated.

🔧 Lucca — Infrastructure Layer Provisioning & Security
  • Compute — Cloudflare Workers (API) + Pages (Dashboard) — or Vercel for Next.js depending on requirements.
  • Database — Neon Serverless PostgreSQL. Dedicated project and credentials per client.
  • Auth & Access — Microsoft Entra ID SSO paired with Cloudflare Zero Trust access policies.
  • DNS & Routing — Automated zone configuration and secure SSL subdomain routing.
  • Storage & Secrets — Dedicated Cloudflare R2 bucket and auto-injected encrypted environment secrets.
💡 Lucca is environment-agnostic. While our default is Cloudflare + Neon, it can provision AWS, Vercel, or Azure where client requirements dictate.
Mocca — Platform & Module Library Product Catalogue
  • Mocca_Client — The white-label core dashboard shell, including sidebar navigation, authentication context, and core user systems.
  • BoardRM — Board portal module including meetings, agendas, resolutions, document storage, and signature routing.
  • CRM_Base — Sales pipeline, client lifecycle management, and core contact tracking.
  • Mocca_Workflow — Unified approvals engine, automated task assignment, and trigger systems.
  • Integrations — Pluggable connectors for third-party systems like Xero, SAP, NetSuite, and HubSpot.
🍮 Panna — Client Instance Composed Environment
  • Tailored Assembly — A client-specific build combining the Mocca_Client shell, chosen operational modules, and required integration connectors.
  • Absolute Isolation — Zero shared resources. A client instance owns its data, codebase, infrastructure parameters, and lifecycle.

The Module Catalogue

Every feature inside Mio's system is treated as a pluggable, isolated module. This guarantees that code is clean, self-contained, and easily composed.

Mocca_Client

✅ BUILT & CORE

The dashboard shell, navigation menu, notification bell, command palette, and base configurations.

BoardRM

✅ BUILT

Governance module. Includes meetings organizer, document vault, RSVP responder, and resolution sign-off.

CRM_Base

🔜 PLANNED

Client onboarding, lead tracking, engagement timelines, and team assignment boards.

Mocca_Workflow

🔜 PLANNED

Custom step automation, approval routing, task queues, and automated alerting systems.

Pluggable Integrations

Xero Integration

✅ ACTIVE

Bi-directional sync of contacts, invoices, quotes, and payment records.

ERP Integrations

🔜 PLANNED

Adapters for enterprise planning systems: SAP, NetSuite, and Microsoft Dynamics 365 Business Central.

HubSpot & CRM Sync

🔜 PLANNED

Connectors to synchronize pipelines, active contacts, and status updates.

Local Accounts & E-Commerce

🔜 PLANNED

Integrations built for Accredo ERP and Shopify e-commerce engines.

Git Repository Structure

Git serves as the single source of truth. Each module lives in its own repository, enabling independent versioning, isolated CI/CD testing, and custom composition per client.

Module Repositories (Independent)

Each module is hosted in its own repository, declaring its specific database schemas, API endpoints, dashboard viewpages, and migrations.

  • 📁 mioltd/mocca-client
  • 📁 mioltd/board-rm
  • 📁 mioltd/crm-base
  • 📁 mioltd/integration-xero

Client Repository (Composed)

A client environment repository pulls in designated module packages via npm or git submodules, governed by their module manifest.

  • 📁 mioltd/panna
  • ├── 📄 manifest.json (Module Registry)
  • ├── 📁 apps/api/ (composes active API routes)
  • ├── 📁 apps/dashboard/ (composes active UI pages)
  • └── 📁 migrations/ (composed DB schema)
This structure ensures independent lifecycles. Panna can utilize BoardRM v1.3 while another client deploys the newer BoardRM v2.0 without version conflicts or code pollution.

The Module Registry (manifest.json)

The manifest.json is the declaration of a client's environment. It dictates what gets built, what routes get exposed, what schemas are configured, and what infrastructure gets provisioned.

{
  "client": {
    "name": "Panna",
    "slug": "panna",
    "domain": "panna.mocca.nz"
  },
  "infrastructure": {
    "provider": "cloudflare",
    "database": "neon",
    "auth": "microsoft-sso"
  },
  "modules": {
    "mocca_client": { "enabled": true, "version": "latest" },
    "crm_base": { "enabled": true, "version": "1.2.0" },
    "board_rm": { "enabled": false },
    "integrations": {
      "xero": { "enabled": true }
    }
  }
}

The Deployment Cascade

By reading the manifest.json, the deployment flow programmatically builds out the client instance.

Developer Pushes manifest.json
Lucca Provisions Infrastructure (DB, Compute, DNS, SSO)
Mocca Composes Code & Schema Migrations
API Workers & Dashboard Bundles Built
✅ Client Environment Live
Deployment Task Manual Provisioning Lucca Automated Provisioning
Database Allocation Neon dashboard configuration Programmatic Neon project launch
Compute Setup Wrangler setup & project link Wrangler pages & worker allocation
SSO Application Registration Microsoft Entra admin steps Automated tenant application link
Secret Injection Copy-pasting variables Automated secure key storage injection
DB Migrations Manual local CLI migration execution Automated migration run via runner
Total Duration ~2 hours ~2 minutes

Daily Iterations & Updates

Once deployed, the client repository receives continuous iterations and updates, propagating platform changes while preserving specific customizations.

Module Updates

Updates, enhancements, and security fixes made inside core module repositories automatically propagate to client environments using that module.

Client Customization

Unique reports, localized logic, or bespoke integrations can be written directly into the client's dedicated repository without code drift or pollution.