AUDIT: Platform Deep Dive & Status Report

Executive Summary

╔══════════════════════════════════════════════════════════════════════╗
║                                                                      ║
║    █████╗ ██╗   ██╗██████╗ ██╗████████╗                              ║
║   ██╔══██╗██║   ██║██╔══██╗██║╚══██╔══╝                              ║
║   ███████║██║   ██║██║  ██║██║   ██║                                 ║
║   ██╔══██║██║   ██║██║  ██║██║   ██║                                 ║
║   ██║  ██║╚██████╔╝██████╔╝██║   ██║                                 ║
║   ╚═╝  ╚═╝ ╚═════╝ ╚═════╝ ╚═╝   ╚═╝                                 ║
║                                                                      ║
║   P L A T F O R M   D E E P   D I V E                               ║
║                                                                      ║
║   Magic e-VERSE  --  Full Infrastructure Audit                      ║
║   Docker · Backend · Storefront · Security · Scalability            ║
║                                                                      ║
║   Date: March 2026                                                  ║
╚══════════════════════════════════════════════════════════════════════╝

This document is a comprehensive audit of the entire Magic e-VERSE platform based on deep analysis of every layer of the stack. It covers the current state, identifies issues by severity, and provides actionable recommendations.

Overall Scorecard

Area	Score	Status
Docker Architecture	6/10	Good foundations, security gaps
Backend Codebase	5/10	Solid features, critical security flaws
Storefront	7/10	Modern stack, some risky choices
Infrastructure	6/10	Operational but needs hardening
Code Distribution	5/10	Works but manual and fragile
Security	3/10	Critical issues requiring immediate action
Scalability	5/10	Adequate for now, won’t scale much further

Platform at a Glance

9 commerce tenants plus master billing portal and PIM system
54+ running containers across the server
Medusa v2 backend (v2.13.1) with custom APLT B2B module
Next.js 15 storefront with React 19 RC
PostgreSQL 16, 12 Redis instances, 9 Meilisearch instances
3 n8n instances for workflow automation
Single server running everything (8 cores, 15GB RAM)

1. Docker Architecture

What’s Good

Multi-stage builds on all Dockerfiles (4-stage backend, 3-stage storefront)
Non-root user execution (medusa UID 1001, nextjs UID 1001)
Alpine base images for minimal footprint
Well-organized port slot system with 10-port ranges per tenant
Per-tenant network isolation via Docker bridge networks
Health checks on Redis and Meilisearch services
Service dependency ordering with depends_on: condition: service_healthy
.dockerignore files present to reduce build context

What’s Problematic

Critical: no CPU or memory limits configured on containers
Production port collisions: tenants reuse 3003 and 9003 in prod configs
:latest image tags in production reduce reproducibility
No backend health checks, only Redis and Meilisearch checks
Massive config duplication: 4,856 lines across 18 docker-compose files with 80%+ duplication
Port numbering inconsistencies: magic_spranz uses 4091, magic_logohorloge uses 6381
No logging configuration, rotation, or centralized logging
Windows path references in production configs (D:/pim_data) that won’t work on Linux

Container Inventory

Tenant	Backend	Frontend	Redis	API	Meilisearch	Database
development	4010	10010	6310	7010	7715	`magic_b2b_development`
demo	4020	10020	6320	7020	7720	`magic_b2b_demo`
default	4030	10030	6330	7030	7730	`magic_b2b_default`
brinxx	4040	10040	6340	7040	7740	`magic_b2b_brinxx`
bovisales	4050	10050	6350	7050	7750	`magic_b2b_bovisales`
desluis	4060	10060	6360	7060	7760	`magic_b2b_desluis`
jodasign	4070	10070	6370	7070	7770	`magic_b2b_jodasign`
logohorloge	4080	10080	6381	7080	7780	`magic_b2b_logohorloge`
spranz	4091	10090	6391	7090	7710	`magic_b2b_spranz`
master_magic	4059	—	6390	7059	—	`master_magic`
PIM	4002	10002	6380	7992	—	`magic_pim`

2. Backend Codebase (Medusa v2)

Architecture Overview

The backend is built on Medusa v2.13.1 with extensive custom B2B and printing business logic:

95 API route files across admin and store APIs
47,000+ lines of TypeScript in 113 source files
29 React admin components for custom admin UI
6 supplier connector integrations: Spranz, XDConnect, PF Concept, Mid Ocean, Toppoint
Custom APLT module for quotations, orders, invoices, customers, techniques, and pricing

What’s Good

Modular API structure with clear admin/store separation
Parameterized SQL queries used widely
TypeScript strict null checks enabled
Multi-language support built into the schema
Comprehensive B2B features including quotation-to-order conversion, franco limits, technique pricing, and discount groups

What’s Problematic

Critical: unauthenticated code execution risk in Dev Projects routes
14 dev-project routes have AUTHENTICATE = false
No consistent request-body validation
File path traversal risk in the editor endpoint
Near-zero test coverage despite Jest configuration
No structured logging beyond console.error
Inconsistent error handling across routes
Database connection leaks from module-scoped clients
No proper database migration system
Version misalignment between Brinxx (v2.13.1) and master_magic (v2.11.3)
Hardcoded /mnt/data/ paths throughout the codebase
No API documentation for 95 routes
any types are still common

Backend Quality Scorecard

Category	Score	Notes
Architecture	7/10	Modular, clear separation
Code Organization	8/10	Good naming, logical structure
Type Safety	6/10	TS enabled but many `any` types
Testing	1/10	Essentially zero coverage
Error Handling	5/10	Inconsistent patterns
Security	3/10	Unauthenticated critical endpoints
Documentation	2/10	Minimal comments, no API docs
Performance	5/10	No caching, blocking syncs

3. Storefront (Next.js 15)

Architecture Overview

Next.js 15 with App Router and React 19 RC
217 component files across 18 feature modules
Tailwind CSS plus CSS variable theming
4 languages: Dutch, German, French, English
Multi-brand support via environment variables and CSS overrides

What’s Good

Server Components by default
Modular feature architecture with 18 self-contained modules
CSS variable theming for multi-tenant branding
Path aliases for clean imports
Standalone Docker output for smaller production images
ISR and ISG hybrid caching strategy
Domain-based brand detection with fallbacks

What’s Problematic

React 19 RC in production
TypeScript and ESLint errors are ignored during build
reactStrictMode: false
dynamic = 'force-dynamic' on product pages disables caching
No Web Vitals monitoring
Hardcoded brand configs in code
All i18n translations loaded upfront
No JSON-LD structured data
No sitemap generation integrated into build

4. Infrastructure & Networking

System Resources

Resource	Value	Status
CPU	8 cores	Adequate
RAM	15 GB (47% used)	Healthy headroom
Root Disk	228 GB (68% used)	Approaching caution
Data Disk (NVMe)	1.8 TB (37% used)	Healthy
Backup Disk (SDB)	916 GB (61% used)	OK
NAS Backup	2.7 TB (13% used)	Plenty of space
Full Backup (NFS)	3.5 TB (39% used)	OK
Containers Running	54	High density
Docker Images	490 GB (1,173 images)	Needs cleanup

Nginx Configuration

Strengths:

Comprehensive security headers
Rate limiting on login endpoints
TLS 1.2 and 1.3 only
Let’s Encrypt auto-renewal every 12 hours
Custom device authentication with IP whitelisting
Hidden server tokens

Weaknesses:

No WAF
No DDoS protection beyond basic rate limiting
Device auth cache only 5 seconds

Database Infrastructure

PostgreSQL 16:

All 9 tenants share one PostgreSQL container
Separate database per tenant (magic_b2b_{tenant})
No connection pooling
sslmode=disable on all connections
No read replicas

Redis:

Per-tenant isolation
No memory limits configured
No persistence configured
No replication for HA

Meilisearch:

Per-tenant search indexes
All healthy
Predictable master keys ({tenant}_meili_master_key_2026)

Supporting Services

Service	Status	Notes
n8n (3 instances)	Running	SQLite database, not production-ready
Nextcloud	Healthy	Document management
OnlyOffice	Healthy	Web document editor
Vaultwarden	Healthy	Password manager (localhost only)
Sshwifty	Running	Web SSH terminal (localhost only)
Omada Controller	Healthy	Network management
rembg-service	Healthy	AI background removal
preflight-service	UNHEALTHY	4,272 failing health checks

Backup Strategy

NAS backup at /mnt/nas-backup/ (last updated Mar 2)
Full backup at /mnt/fullbackup/ with weekly/monthly snapshots
No automated database backup defined in Docker configs
No visible backup encryption
No documented restore procedure

5. Code Distribution & Tenant Management

Current Workflow

Brinxx (source) -> Development (staging) -> 7 other tenants
Git branches for features using PROJ-2026-XXXX
Single git repository at /mnt/data/magic_omniverse/magic_commerce/
Bare repo backup at /mnt/data/magic_omniverse/magic_commerce.git/
All tenants share one codebase and differ by environment variables
Tenant-specific files excluded via .gitignore

PIM Sync Architecture

Central PIM database syncs products to each tenant via JavaScript scripts:

sync-master.js (531 lines) for full product, pricing, and technique sync
sync-prices-only.js (153 lines) for price-only updates
Manual trigger only
No confirmation or rollback mechanism
No transaction support, so partial syncs are possible

What’s Problematic

No CI/CD pipeline
Deployments are manual: git pull plus docker compose build
Inconsistent versions across tenants
No automated testing or validation before deployment
Configuration drift risk because tenant-specific files are untracked
No deployment rollback mechanism
master_magic template is behind Brinxx

6. Security Assessment

Overall Security Rating: 3/10 and requires critical action.

Critical Findings

1. Hardcoded Secrets in Source Code

Secret	Location	Severity
`ANTHROPIC_API_KEY=process.env.ANTHROPIC_API_KEY...`	All 10 `docker-compose.yml` files	CRITICAL
`DATABASE_URL=...<your-db-password>@...`	All 37 occurrences	CRITICAL
`JWT_SECRET=supersecret`	29 occurrences	CRITICAL
`COOKIE_SECRET=supersecret`	29 occurrences	CRITICAL
`MEILI_MASTER_KEY={tenant}_meili_master_key_2026`	All tenants	CRITICAL
Nextcloud passwords	`magic_docs/docker-compose.yml`	CRITICAL

All of these are committed to git and visible in version history.

2. Unauthenticated Admin Endpoints

The Dev Projects feature exposes 14 routes with AUTHENTICATE = false:

Endpoint	Risk
`POST /admin/dev-projects/commit`	Create git commits
`GET /admin/dev-projects/editor`	Read any file
`POST /admin/dev-projects/rebuild`	Rebuild the application
`GET /admin/dev-projects/git`	View git status
`GET /admin/dev-projects/browse`	Browse directories
`GET /admin/dev-projects/files`	Access files
`GET /admin/dev-projects/diff`	View diffs

These allow unauthenticated arbitrary file read and code execution if perimeter controls fail.

3. Unencrypted Database Connections

All database connections use sslmode=disable.

4. No RBAC

No fine-grained authorization in admin API
All admins can access all data
No audit logging of data access

5. Exposed Network Services

490GB of Docker images on disk expands attack surface
preflight-service is unhealthy with 4,272 restart attempts
No WAF or DDoS protection beyond basic rate limiting

7. Scalability Assessment

Current Capacity

The platform currently runs 9 tenants on a single server with 8 cores, 15GB RAM, and 54+ containers. That is approaching the practical limit.

Bottlenecks

Bottleneck	Impact	Limit
Single PostgreSQL	All tenants share one DB	~20-30 tenants before connection exhaustion
No connection pooling	Direct connections per request	~100 concurrent connections per backend
Single server	Everything on one machine	Hardware failure = total outage
Manual deployment	Human bottleneck	Adding tenants takes hours
Docker Compose only	No orchestration	Cannot distribute across machines
Blocking syncs	Supplier syncs block request threads	Slow under load
No CDN	All static assets served from origin	Latency for distant users
Build cache 0B	Every build starts from scratch	20+ minute builds

Scaling Recommendations by Timeline

Immediate:

Add PgBouncer for connection pooling
Set container resource limits
Clean up Docker images
Add Docker build cache

Short-term (1-3 months):

Move to Docker Swarm for basic orchestration
Add PostgreSQL read replicas
Implement Redis Sentinel for HA
Add CDN for static assets
Migrate n8n from SQLite to PostgreSQL

Long-term (6-12 months):

Kubernetes migration for multi-node scaling
Multi-region deployment with disaster recovery
Service mesh for advanced networking
Database partitioning by tenant

8. Action Plan — Priority Order

CRITICAL — This Week

Rotate all exposed secrets and move them to .env files or Docker secrets
Authenticate or disable all Dev Projects endpoints and validate file paths
Fix or remove preflight-service

HIGH — This Month

Add container resource limits
Enable database SSL
Add backend health checks
Implement connection pooling
Fix TypeScript and ESLint build errors
Synchronize Medusa versions

MEDIUM — Next Quarter

Implement CI/CD pipeline
Add test coverage on revenue-critical paths
Consolidate Docker configs
Add centralized monitoring
Implement proper database migrations
Add API documentation
Move from React 19 RC to a stable release
Automate PIM sync with confirmation, rollback, and notifications

LOW — This Year

Clean up Docker images
Move brand configs to database
Add per-language code splitting
Implement Web Vitals monitoring
Add JSON-LD for product SEO
Implement Redis persistence
Add WAF protection
Plan Kubernetes migration

Appendix A: File Locations

Component	Path
Commerce tenants	`/mnt/data/magic_omniverse/magic_commerce/magic_{tenant}/`
Master template	`/mnt/data/magic_omniverse/magic_commerce/master_magic/`
PIM system	`/mnt/data/magic_pim/`
Bare git repo	`/mnt/data/magic_omniverse/magic_commerce.git/`
Nginx configs	`/etc/nginx/sites-available/`
Device auth	`/etc/nginx/snippets/device-auth.conf`
DevDocs source	`/mnt/data/magic_omniverse/magic_docs/starlight/`
Docker images	`490GB` across `1,173` images
Backups	`/mnt/nas-backup/`, `/mnt/fullbackup/`

Appendix B: Technology Stack

Layer	Technology	Version
Backend Framework	Medusa	`v2.13.1`
Backend Runtime	Node.js	`22/24 (Alpine)`
Frontend Framework	Next.js	`15`
Frontend Runtime	React	`19 RC`
Database	PostgreSQL	`16 (Alpine)`
Cache	Redis	`7 (Alpine)`
Search	Meilisearch	`v1.6`
Styling	Tailwind CSS	`3.0.23`
Language	TypeScript	`5.3-5.6`
Container	Docker Compose	`v5.0.0`
Reverse Proxy	Nginx	`Latest`
SSL	Let’s Encrypt	`Auto-renewal`
Automation	n8n	`1.122.4`
Docs	Astro Starlight	`Latest`

This audit was generated on March 4, 2026 by analyzing every layer of the Magic e-VERSE platform using 6 parallel deep-dive agents examining Docker architecture, backend codebase, storefront codebase, infrastructure and networking, code distribution, and security posture.