YukonIT admin backend study (2026-10-17)

Scope: compare the two admin backend options on the table for the YukonIT pilot and recommend one — or, as the evidence suggests, the hybrid that uses both. YukonIT services: KB + EVE + Medusa + StoreFront (an existing trading hosting business at yukonit.com.au, not a blank slate). This is a study doc (specs only — no build, no execution).

Pilot context (from vercel-platform-products-study §5.2 and product-catalogue-vercel-grounded §2.2): YukonIT is already a trading hosting operator. We are adding KB + EVE + Medusa + storefront to an existing operator who will judge us by whether our stack beats what they already sell. Delivery set = P1 (KB) + P2 (storefront) + P4 (EVE) + hosting = the full bundle, the A$119 tier proof.

The question Young put to us: which admin backend — Nuxt UI Pro Dashboard (frontend admin surface) or Medusa V2 Admin (built-in commerce admin) + POS (Agilo MIT) + KB with EVE receptionist?

Short answer: they are not competitors. Nuxt UI Pro Dashboard is the customer-facing admin frontend; Medusa V2 Admin is the commerce backend. Use both, wired together: Nuxt UI Pro Dashboard as the operator-facing UI shell that YukonIT staff actually touch, Medusa V2 Admin as the commerce engine underneath (product/order/customer management, POS, inventory, fulfillment). The KB + EVE receptionist sits beside them as the self-help + first-line support layer. Recommendation: hybrid (Option 3) — neither Option 1 nor Option 2 alone.

1. What each option gives us

1.1 Option 1 — Nuxt UI Pro Dashboard (frontend admin only)

Source: nuxt-ui-pro/dashboard ★1,093, MIT; listed in products-from-vercel-templates and vercel-platform-products-study as the "OpsDashboard" product family.

Gives us:

• 15+ ready-made dashboard components — multi-column layouts, charts, date pickers, resizable panels, sidebar navigation, command palette, data tables, forms, toasts, modals. Built on Nuxt UI + Tailwind 4 + Nuxt 4 (same stack we already run for Docus/docs.youngle.au).
• A complete, sellable admin shell — MIT licensed, no competing-use restriction, no per-seat metering. We can rebrand, repackage, and sell it as "YukonIT admin console" or as a v2 client ops dashboard product.
• Coherent stack — same Nuxt/Nuxt UI family as our Docus KB sites, our landing pages (Nuxt UI Pro Landing), and our SaaS portals (Nuxt UI Pro SaaS). One component family, one design system, one build pipeline across all five products (KB, BusinessOnline, Commerce+POS, AIAgent, OpsDashboard).
• Customer-facing surface — this is the UI YukonIT staff actually log into. Charts for sales, date pickers for reporting windows, resizable panels for the POS-adjacent layout. It is the thing a non-technical operator sees.
• Internal fleet reuse — v1 internal fleet dashboards already ride this component family (products-from-vercel-templates §3, P5/P7). Building YukonIT's admin on it amortises the same investment.
• No commerce lock-in — it is a pure frontend. It can front any backend (Medusa, our own APIs, EVE). That is what makes it complementary rather than competing.

What it is not: it ships zero commerce logic. No product catalogue, no inventory, no carts, no orders, no customers, no payments, no fulfillment, no POS. It is chrome and layout and components — the empty admin shell that still needs something behind it.

1.2 Option 2 — Medusa V2 Admin (built-in) + POS (Agilo, MIT) + KB with EVE receptionist

Source: medusajs/medusa v2.21.2, MIT core (EE RBAC gated); Agilo/medusa-pos-starter ★121 MIT; EVE vercel/eve ★5,591 Apache-2.0. Verified in medusa-nextjs-commerce-study, medusa-hosting-docker-study, medusa-eve-integration-study.

Gives us (the commerce backend):

• Built-in Admin at <APP_URL>/app — product/order/customer management, inventory, pricing, regions, sales channels, stock locations, promotions/vouchers, fulfillment, returns, staff roles. This is the commerce engine: the data model, the workflows, the Admin REST + Admin API that everything else consumes.
• The data model itself — products/variants, carts, orders, customers, inventory, price lists, regions/channels/locations. Native "sell services" support (products without stock + price lists); bookings/subscriptions layered as a custom module.
• POS (Agilo, MIT) — Expo/React Native, connects to the Admin REST API over HTTPS only (no backend changes). Staff auth with admin credentials, setup wizard (regions/sales channels/stock locations), barcode scan via device camera, cart → draft orders that sync to Admin, order history. Works alongside online channels via sales-channel + inventory modules — products/orders/customers stay unified.
• Multi-channel unification — online storefront + in-store POS share one catalog, one inventory, one order stream. Exactly what a retailer running both needs.
• Commerce workflows — the 4-layer architecture (API routes → Workflows → Modules → Postgres) with swappable infrastructure modules (Redis cache/event bus/ locking/workflow engine, S3 file, SendGrid notification). In-process extension model: custom modules (e.g. services catalogue, bookings) ship inside the one Node app.
• EVE agent integration pattern verified — useEveAgent() React hook, agent/connections/ folder, typed tools with read-scope publishable key vs write-scope admin token behind HIL gates. EVE self-hosted as Nitro beside the Medusa stack (eve build → eve start), per-tenant memory scoping (the SaaS hook).
• Per-tenant Docker stack — measured: ~4.8 GB steady per tenant (server 2 + worker 1 + storefront 1 + PG 0.7 + Redis 0.1), ~4 full tenants per 23 Gi ARM node, server/worker split, health-gated onboarding (/health + /eve/v1/health).
• Licence cleanliness — MIT core + Apache-2.0 EVE. Sellable end-to-end (the licence profile that makes the whole bundle sellable; Saleor Paper's FSL is why Medusa won the comparison).

Gives us (the KB + EVE receptionist):

• KB-for-self-help — the KnowledgeBase product (P1) is a Nuxt/Docus site (nuxt/docus ★3,117 MIT, what docs.youngle.au runs today) hosting company knowledge base + agent-published docs + our vault-mirror pipeline. For YukonIT this is the customer-facing help centre: how to use the POS, return policy, shipping, product care, FAQ. Markdown-authored, agent-publishable.
• EVE receptionist — an EVE agent (Apache-2.0, Nitro self-host) embedded in the storefront via useEveAgent() chat UI, with per-tenant memory scoping. First-line support: order status, product questions, checkout help, refunds behind HIL gates. The "AI receptionist" that neither Medusa Cloud nor Shopify bundles (the wedge).

1.3 What Option 2 lacks (the honest gaps, stated not smoothed)

From medusa-nextjs-commerce-study, 3-package-deep-dive, business-plan:

• POS payments are NOT integrated — Agilo POS has no payment processing yet. Manual payment plugin path exists (cash/bank transfer/terminal, then mark paid in admin). Terminal integrations (Stripe/Adyen) are on Agilo's roadmap, not shipped. This is a known, disclosed gap — price accordingly (sell "website + AI staff" first; POS payments are Phase 2).
• No offline mode in Agilo POS (cached browse only).
• POS auth is coarse — one admin credential per tenant today; per-staff roles are future.
• EVE is beta (Vercel beta terms, API churn expected). Pin @workflow/* to exact versions; adopt for tenants first, fleet later. A bad EVE update propagates to all tenants on next deploy — per-tenant health gate (/eve/v1/health) is the mitigation, not a guarantee.
• Medusa EE (RBAC) is commercial — core is MIT, but RBAC-based Enterprise features sit under ENTERPRISE-LICENSE.md. YukonIT pilot runs on MIT core; RBAC is the feature a fleet-operated shop eventually wants. Plan for the licence boundary.
• Oracle ARM free-tier caveat — node runs 4 OCPU/24 GB against an Always Free allowance of 2 OCPU/12 GB. Excess is billable (~A$40–60/mo if credits expire). Pilot on free tier, production target = paid node.
• "Sell services" is underspecified — Medusa treats services as products without stock; bookings/scheduling need a custom module. Pilot with physical/simple goods first (recommendation from 3-package-deep-dive §3.1).
• Medusa's built-in Admin is functional but not opinionated about our UX — it is the commerce admin, not a tailored operator console. It does not give the charts/date-pickers/resizable-panels experience that Nuxt UI Pro Dashboard does. This is exactly the gap Option 1 fills.

1.4 What Option 1 lacks

• Zero commerce logic — no products, orders, customers, inventory, payments, fulfillment, POS. It is a shell.
• Zero data model — needs a backend (Medusa, or our own) to be anything.
• No POS, no KB, no EVE — those come from Option 2's stack.
• No tenant isolation story of its own — it rides whatever backend hosts it.

2. The recommended hybrid (Option 3)

Nuxt UI Pro Dashboard as the customer-facing admin frontend; Medusa V2 Admin as the commerce backend. They complement, not compete.

2.1 Why they are not competitors

The two options sit at different layers of the same stack:

Option 1 without Option 2 is an empty dashboard. Option 2 without Option 1 is a working commerce backend with a generic admin. The hybrid gives YukonIT both: a tailored, branded operator console on top of a real commerce engine.

2.2 How they wire together

YukonIT operator (browser)
        │
        ▼
┌──────────────────────────────────────────────┐
│  Nuxt UI Pro Dashboard (Nuxt 4, Nuxt UI,     │  ← customer-facing admin frontend
│  Tailwind 4) — charts, tables, date pickers, │     (Option 1, MIT, sellable)
│  resizable panels, command palette           │
└──────────────┬───────────────────────────────┘
               │  HTTPS → Medusa Admin REST API (read/write, scoped tokens)
               │  + our own BFF routes for KB/EVE data
               ▼
┌──────────────────────────────────────────────┐
│  Medusa V2 backend (Node/TS, server+worker)  │  ← commerce backend
│  Postgres 15 · Redis 7                       │     (Option 2, MIT core)
│  products · orders · customers · inventory   │
│  regions · channels · stock locations        │
│  Agilo POS ← Admin REST API (HTTPS)         │
└──────────────┬───────────────────────────────┘
               │
               ▼
┌──────────────────────────────────────────────┐
│  EVE agent (Nitro, Apache-2.0)               │  ← receptionist / first-line support
│  tools (read-scope publishable key)          │
│  skills (refund-playbook, checkout-flow)     │
│  HIL workflows (refund gate)                 │
│  per-tenant memory (file provider)            │
└──────────────┬───────────────────────────────┘
               │
               ▼
┌──────────────────────────────────────────────┐
│  KB / self-help site (Nuxt/Docus, MIT)       │  ← KnowledgeBase product (P1)
│  vault-mirror pipeline · markdown · agent-   │
│  published docs                              │
└──────────────────────────────────────────────┘

Integration rules:

• Nuxt UI Pro Dashboard calls Medusa's Admin REST API for commerce data (products, orders, customers, inventory, promotions). Scoped tokens: read-scope for views, write-scope only behind explicit operator action (and HIL where money moves).
• Medusa's built-in /app admin is NOT removed — it stays as the fallback/ power-user surface and the surface Agilo POS authenticates against. Nuxt UI Pro Dashboard is the operator-facing experience layered on top; Medusa /app is the engine's native admin. Both coexist; the dashboard is the default view for YukonIT staff, /app is the escape hatch.
• EVE agent stays in the storefront + chat channel, not in the admin. Its role is customer-facing receptionist, not operator tooling (see §3).
• KB (Docus) is a separate site at the tenant's domain (e.g. help.yukonit.com.au or docs.yukonit.com.au), linked from the storefront and the dashboard. EVE can read it as a skill source for answering customer questions.

2.3 What this gives YukonIT specifically

• A branded, tailored admin console (their logo, their colours, their dashboard widgets) instead of a generic Medusa admin — YukonIT is a hosting operator; they will judge us on whether our console beats what they already sell.
• Real commerce underneath — products, orders, customers, inventory, POS, all unified, no re-implementation.
• POS on tablets (Agilo, MIT) — same backend, same catalog, same orders. Manual payment path disclosed up front; terminal integrations Phase 2.
• AI receptionist (EVE) on the storefront — order status, product questions, checkout help, refunds behind HIL. The differentiator neither Medusa Cloud nor Shopify bundles.
• KB self-help (Docus) — reduces receptionist load; EVE can cite it.
• Landing + domain + O365 packaged as the entry tier (BusinessOnline) — see §5.

2.4 What this costs us (honest)

• Two admin surfaces to keep aligned — Nuxt UI Pro Dashboard + Medusa /app. Mitigation: dashboard is a view layer; it does not own commerce logic. All mutations go through Medusa's API. No duplicated business rules.
• Dashboard build is ours — Nuxt UI Pro gives components, not a finished YukonIT console. Ace/Sol build the dashboard pages against Medusa's API. This is the "OpsDashboard v2" product work, brought forward for the pilot.
• EVE beta risk remains — pin versions, health-gate, adopt for tenants first.
• POS payments gap remains — disclosed, priced as "website + AI staff" first.

3. EVE receptionist role in the KB flow

EVE is the customer-facing receptionist, not the operator's admin tool. Its place in the KB flow:

3.1 The flow

Customer question (storefront chat / Slack / Telegram)
        │
        ▼
┌──────────────────────────────┐
│  EVE receptionist (Nitro)    │
│  instructions.md = persona    │
│  (tenant-tuned: tone, policy)│
└──────────────┬───────────────┘
               │
       ┌───────┴───────┐
       │               │
       ▼               ▼
┌─────────────┐  ┌──────────────────────┐
│ KB / Docus  │  │ Medusa Store API     │
│ (self-help  │  │ (read-scope publish- │
│  articles)  │  │  able key)           │
│ cite + link │  │ products, carts,     │
│             │  │ order status         │
└─────────────┘  └──────────────────────┘
       │               │
       └───────┬───────┘
               ▼
        Answer + links
               │
       (if action needed: refund, bulk price)
               ▼
┌──────────────────────────────┐
│  HIL gate → admin approval   │
│  → execute via Admin token   │
│  (write-scope, HIL-gated)    │
└──────────────────────────────┘

3.2 Role definition

• First-line support — answers from the KB (self-help articles) and live commerce data (order status, product availability, pricing). Cites KB articles with links so the customer can self-serve next time.
• Checkout assistant — helps with cart, shipping, payment questions; uses read-scope tools (list_products, cart reads). Checkout completion is HIL-gated.
• Order status — durable workflow (order-status-watcher) polls order status and notifies the customer. No human needed for read-only status.
• Refunds / bulk pricing — HIL-gated. EVE pauses, requests admin approval through the dashboard, then executes against the Admin API with the scoped admin token. The operator approves in the Nuxt UI Pro Dashboard; EVE never self-approves (separation of duties — same rule as our fleet).
• Escalation — when EVE cannot resolve (complaint, complex return, VIP), it hands off to a human with a summary. Does not pretend to resolve.

3.3 KB-for-self-help specifics

• KB is the source of truth for policy — returns policy, shipping times, care instructions, FAQ, POS how-to. EVE reads it as a skill source; KB articles are the canonical answer, EVE is the delivery channel.
• KB reduces receptionist load — every question EVE can answer from KB is one less ticket. Success metric: % of conversations resolved without escalation.
• KB is agent-publishable — our vault-mirror pipeline (Docus + Nuxt Content) means EVE (or our fleet agents) can publish new articles from resolved conversations. The KB grows from real support traffic.
• Per-tenant scoping — KB content is per-tenant (YukonIT's KB is theirs; not shared across tenants). EVE memory is per-tenant (file provider, tenant-scoped) so conversations do not leak between tenants.

3.4 What EVE does NOT do

• Does not run the admin console (that is Nuxt UI Pro Dashboard + Medusa /app).
• Does not self-approve money movement (HIL gate required).
• Does not hold write-scope keys outside HIL workflows (publishable key for storefront reads; admin token only inside approved workflows).
• Does not replace the KB — it cites it.

4. O365 integration notes

From services-pricing-model-aud §2 and product-catalogue-vercel-grounded: M365 email is a packaged add-on in the Solo/Shop tiers, not part of the admin backend itself. Integration notes for the YukonIT bundle:

• What it is: Microsoft 365 Business Basic (AU$10.50/user retail; our price A$15.00/user = 1.43× Microsoft, includes setup + alias management). Margin A$4.50/user/mo — we sell setup and management, not the licence.
• Scope for YukonIT (Solo tier): 1 M365 user included (A$15/mo). Shop tier: 3 users (A$45/mo). Extra users at A$15/user/mo.
• Integration surface: domain registration + DNS (MX, SPF, DKIM, DMARC) + M365 tenant provisioning + alias management. This is ops work, not code — onboarding script step, not a build item.
• Domain dependency: M365 requires the tenant's domain to be registered and DNS-controlled by us (or transferred). YukonIT already owns yukonit.com.au and runs a hosting business on it — coexistence question (see §6 open items). We may need a subdomain strategy (e.g. shop.yukonit.com.au, help.yukonit.com.au) rather than taking over the apex.
• Admin implication: M365 admin is Microsoft's, not ours. Our Nuxt UI Pro Dashboard does not manage M365; it links out to the M365 admin centre. We do not build an email admin surface.
• Pricing anchor: A$5/mo domain + A$15/user/mo M365 are the entry-tier add-ons that make the package feel complete (domain is the anchor, not the profit centre).

5. Landing page + domain setup

From vercel-platform-products-study §5.2, product-catalogue-vercel-grounded §2.2, prod-services-lane-redesign §5/§9.

5.1 YukonIT domain state (measured)

• yukonit.com.au — 200, live, and not ours: <title>Domain Names & Web Hosting | Yukon IT Pty Ltd — an existing hosting business site.
• YukonIT is already a trading hosting operator. We are not building a shop for a blank slate; we are adding KB + EVE + Medusa + storefront to an existing operator.
• Coexistence is an integration question (Sol), not a pricing one: our stack must run alongside their current platform without disturbing it.

5.2 Recommended domain strategy (specs only)

Because YukonIT's apex already serves their hosting business, we do not take over yukonit.com.au. Instead:

• TLS: per-domain certs via the existing letsencrypt pattern on the node's nginx. Wildcard vs per-domain is an open decision (Sol).
• Admin surface binds to tailnet by default (per docker-systems-design §3.4) — admin.yukonit.com.au is not publicly exposed unless explicitly opened.
• nginx vhosts added as new files in sites-enabled/, never editing the existing four (docs.youngle.au, pulse.youngle.au, sol.youngle.au, yukonit.youngle.au). A tenant onboarding that touches those is a defect.

5.3 Landing page

• YukonIT's own apex landing is theirs and stays. Our "landing" for the pilot is the storefront at shop.yukonit.com.au plus the KB at help.yukonit.com.au.
• The showcase landing (the apex youngle.au page that is currently missing — HTTP 000) is a separate, our-own-content-pipeline build (P5). It is where we demonstrate the bundle to prospective tenants; YukonIT is the first case study featured on it (with their permission).
• BusinessOnline (Landing + domain + O365) as a product (P2/P5) is the entry tier we sell to other prospects; YukonIT's bundle is the full package (P1+P2+P4+hosting).

6. YukonIT services: KB + EVE + Medusa + StoreFront — mapping to the hybrid

All five products (KB, BusinessOnline, Commerce+POS, AIAgent, OpsDashboard) ride the same Nuxt+Docker stack — the showcase story is coherent: "everything you see on docs.youngle.au is the same machinery your business runs on."

7. Recommended decision

Go hybrid. Nuxt UI Pro Dashboard (frontend admin) + Medusa V2 Admin (commerce backend) + EVE receptionist + KB self-help + landing/domain/O365 packaging.

Reasons:

1. They are different layers, not alternatives. Option 1 is chrome; Option 2 is the engine. Choosing one forfeits the other's value.
2. YukonIT judges us on the console. They are a hosting operator; a generic Medusa /app will not beat what they already sell. Nuxt UI Pro Dashboard gives a branded, tailored, sellable operator console (also becomes the OpsDashboard v2 product).
3. Commerce logic is not ours to rebuild. Medusa's data model, workflows, POS, inventory, multi-channel unification are verified, MIT, and measured. Re-implementing them behind a Nuxt dashboard would be the V2 "built-never-wired" defect all over again.
4. EVE + KB are the wedge — the differentiator neither Medusa Cloud nor Shopify bundles. They sit beside the hybrid, not inside either option.
5. Licence profile stays clean — MIT + MIT + Apache-2.0, no competing-use restriction, no per-seat metering, sellable end-to-end.

7.1 What we are NOT recommending

• Option 1 alone — an empty dashboard with no commerce engine. YukonIT gets nothing sellable.
• Option 2 alone — a working backend with a generic admin. Underwhelming for an operator who already sells hosting consoles; forfeits the sellable OpsDashboard product and the branded experience.
• Replacing Medusa /app with the Nuxt dashboard — keep both. The dashboard is the view; /app is the engine's native admin and the POS auth surface. No duplicated business rules.

8. Open items (not decided here)

1. YukonIT scope — KB + EVE + Medusa + storefront as one pilot bundle, or phased? (Mira: pricing; Sol: integration with their current platform.)
2. Coexistence — how our stack runs alongside YukonIT's existing hosting platform without disturbing it. (Sol integration question.)
3. POS payments — Phase 2 (terminal integrations) or pilot requirement? Current recommendation: manual path first, disclose at sale.
4. EVE beta risk — accept with mitigations (pin @workflow/*, per-tenant health gate, adopt for tenants first). Young's call.
5. Oracle ARM free tier — pilot on free, production on paid node. OCI console check outstanding (Mira).
6. "Sell services" vertical — physical/simple goods first, then services catalogue module (custom Medusa module). Recommendation from 3-package-deep-dive §3.1.
7. Wildcard vs per-domain TLS — Sol.
8. M365 reseller vs retail — AU$10.50 is retail; reseller account may lower cost. (Mira.)
9. Dashboard scope for pilot — which widgets/pages ship in v1 of the YukonIT console vs deferred to OpsDashboard v2. (Nova/Sol.)
10. MCP ruling — pending Young (OPEN-DECISIONS item 4); not blocking this study.

9. Sources

All claims trace to verified vault docs (live-probed or measured, 2026-10-13 to 2026-10-17). No new measurements introduced here.

• 01-research/vercel-platform-products-study.md — Vercel template landscape, product catalogue (5 products), pilot mapping, tiers.
• 01-research/products-from-vercel-templates.md — offer catalogue, licences, pilot mapping (Tam).
• 01-research/medusa-eve-integration-study.md — Medusa × EVE integration, combined architecture, HIL + key scoping, build sequencing.
• 01-research/medusa-hosting-docker-study.md — per-tenant Docker stack, sizing, Oracle ARM capacity, onboarding script.
• 01-research/medusa-nextjs-commerce-study.md — Medusa v2 MIT, dtc-starter, Agilo POS (MIT, Admin REST, MVP gaps), licence matrix.
• 01-research/hermes-eve-cohosting-study.md — EVE framework vs Hermes, RAM budget, self-host topology, version pinning.
• 01-research/3-package-deep-dive.md — gaps (services vs goods, EVE beta, POS payments, multi-tenant memory, Oracle free tier).
• 01-research/unified-package-deepdive.md — packaging mechanics, tier ladder.
• 01-research/ecommerce-study.md — Saleor vs Medusa comparison, licence gates.
• 02-architecture/docker-systems-design.md — per-tenant compose, isolation, resource ceilings, onboarding, Tailscale private plane.
• 02-architecture/prod-services-lane-redesign.md — prod services lane, pilot tenants, Nuxt sites on prod.
• 02-architecture/COMMERCE-HOSTING-DESIGN-2026-10-13.md — tenant template, secrets register, EVE template, POS integration, multi-env, update pipeline.
• 03-decisions/business-plan-v2-aud-allowance.md — pricing tiers AUD, unit economics, competitor bench.
• 03-decisions/services-pricing-model-aud.md — domain, M365, storage, bandwidth, compute, AI cost model.
• 03-decisions/product-catalogue-vercel-grounded.md — product ladder, pilot mapping, showcase angle.
• 03-decisions/business-plan-hosted-commerce-pos-ai-staff.md — 3-in-1 package, GTM, risk register.

Register note: this study compares the two admin backend options for YukonIT and recommends the hybrid (Nuxt UI Pro Dashboard as customer-facing admin frontend + Medusa V2 Admin as commerce backend). It is a research note; no build, no execution. Companion: vercel-platform-products-study.md (product landscape) and prod-services-lane-redesign.md (architecture). YukonIT is pilot 2 (full bundle, A$119 tier target).