Open Mercato: Modular enterprise CRM/ERP and extensible commerce backend
A modular enterprise CRM/ERP and commerce backend offering multi-tenancy, field-level encryption, an AI assistant and per-module migrations—suited for teams needing heavy customization and rapid delivery; license and community signals warrant due diligence before production use.
GitHub open-mercato/open-mercato Updated 2026-02-20 Branch main Stars 717 Forks 113
TypeScript Next.js Multi-tenant Modular architecture Headless API Field-level encryption AI Assistant MikroORM Meilisearch RBAC

💡 Deep Analysis

5
What are the advantages of the modular monorepo with per-module ORM entities, and what migration/dependency considerations should be accounted for?

Core Analysis

Core Question: Modular monorepo with per-module ORM entities improves reuse and reduces coupling, but increases complexity in DB migrations and cross-module entity dependencies, requiring explicit management.

Technical Analysis

  • Advantages:
  • Clear module boundaries: Each module self-contains frontend, backend, and entities, easing independent development and reuse.
  • Overlay/override support: Allows injecting custom modules or overrides into production-ready modules, reducing invasive changes.

  • Testability: Modules are easier to cover with unit and integration tests.

  • Risks & Challenges:

  • Migration order & dependencies: Cross-module foreign keys or composite indexes require enforced migration ordering, or migrations can block/startup fail.
  • Rollback complexity: Rolling back a single module can break data integrity in dependent modules.
  • Implicit global schema: Even without a global schema file, the DB is shared — changes must be coordinated.

Practical Recommendations

  1. Add migration dependency metadata: Tag module migrations with depends_on and apply in topological order in CI.
  2. Practice migration drills: Rehearse multi-module migration and rollback scenarios in staging.
  3. Avoid cross-module FKs when possible: For tightly coupled tables, colocate them in one module or use logical references with programmatic integrity checks.
  4. Use post-migration validation hooks: Run integrity checks after migrations to confirm FK/index/data consistency.

Important Notice: Modularization is not a silver bullet for DB complexity — it requires process discipline, CI validation, and cross-team coordination.

Summary: For mid-to-large teams, the modular monorepo yields strong parallel development and reuse benefits, but mitigate DB consistency risk via migration dependency management, rehearsals, and CI checks.

85.0%
How is Open Mercato's field-level encryption designed, and what operational challenges should teams expect in production?

Core Analysis

Core Question: Open Mercato integrates field-level encryption into the ORM lifecycle using per-tenant DEKs backed by KMS/Vault. This offers transparent data protection but introduces operational challenges around key management, query capability trade-offs, and performance/recovery considerations.

Technical Analysis

  • Implementation Highlights:
  • Per-tenant DEKs, preferably backed by KMS/Vault.
  • AES-GCM used for transparent encryption/decryption in ORM hooks.

  • Deterministic hashing (e.g., email_hash) or search-layer synchronization (JSONB/Meilisearch) for searchable fields.

  • Operational Challenges:

  • Key management risk: Misconfiguration or DEK loss can render historical data undecryptable; KMS must be highly available and audited.
  • Query/index trade-offs: Encrypted fields cannot support full-text or range queries; maintain additional hash indexes or a search tier and keep them in sync.
  • Performance impact: Encryption/decryption adds CPU and latency; batch operations need strategies to avoid throughput bottlenecks.

Practical Recommendations

  1. Prefer managed KMS/Vault: Use per-tenant DEKs, rotate keys periodically and test recovery procedures.
  2. Design query strategy: Use deterministic hash indexes for equality lookups and offload search needs to Meilisearch/JSONB hybrid indexing.
  3. Monitor crypto latency: Collect ORM hook latency, and consider short-term caching or asynchronous decryption for high-concurrency paths (mind the sensitivity of caches).
  4. Practice recovery drills: Regularly test DEK rotation and loss scenarios in staging.

Important Notice: If your team cannot guarantee correct and highly available KMS configuration, field-level encryption risks unrecoverable data.

Summary: The approach satisfies compliance and protection goals but requires firm operational practices in key management, search/index design, and performance planning.

85.0%
What learning curve and common issues will development teams encounter when adopting Open Mercato, and how can they onboard efficiently?

Core Analysis

Core Question: Open Mercato requires solid familiarity with TypeScript/Next.js, MikroORM, Awilix, and multi-tenant/encryption concepts. The main onboarding challenges are environment dependencies, migration management, and key configuration.

Technical Analysis (Learning Cost & Common Issues)

  • Sources of learning cost:
  • Strict version constraints (Node 24, Yarn 4).
  • Understanding modules that include frontend, backend, and entities plus per-module migrations.

  • Using Awilix request-scoped DI and MikroORM lifecycle hooks (used for encryption) and multi-tenant data partitioning.

  • Common pitfalls:

  • Env/path changes causing startup failures or lost storage (.env and storage dirs).
  • Migration-order conflicts or cross-module FKs causing migration failures.
  • Misconfigured KMS/Vault or fallback keys leading to undecryptable data.
  • Misconfigured multi-tenant permissions leading to authorization leaks.

Efficient Onboarding Recommendations

  1. Onboard in phases:
    - Step 1: Set up local dev with Node 24 and Yarn 4; run yarn generate / yarn initialize.
    - Step 2: Enable core modules (users, organizations, auth) and validate E2E auth and role flows.
    - Step 3: Add products/orders, run migrations, validate FKs and indexes.
    - Step 4: Enable encryption/KMS and rehearse key rotation/recovery in staging.

  2. CI & drills: Include module migration order validation, integration tests, and rollback drills in CI.

  3. Documentation & conventions: Maintain migration dependency docs, semantic versioning, and rollback procedures per module.

Important Notice: Never configure KMS or run critical migrations first in production—always rehearse in staging.

Summary: By phasing adoption, adding CI validation, and performing key-recovery drills, teams can overcome the initial learning curve and make Open Mercato a reliable production platform.

85.0%
How effective is Open Mercato's multi-tenant and organizational hierarchy model for fine-grained permissions, and what configuration/testing points are essential?

Core Analysis

Core Question: Open Mercato embeds multi-tenancy and org-hierarchy at the entity level (tenant_id + organization_id) and offers feature-based RBAC — this is a solid foundation for fine-grained permissions, but production-grade security requires API/UI enforcement and thorough testing.

Technical Analysis

  • Base capabilities:
  • Entity-level isolation: tenant_id/organization_id on entities enforces data-layer isolation.
  • Org trees & scoping: Multi-level orgs support visibility and team/department partitioning.

  • Feature RBAC: Role- and user-level feature flags allow gating pages and APIs per org.

  • Points of caution:

  • Query path consistency: Every query must include proper org/tenant filters to avoid unauthorized access.
  • Business semantic permissions: Attribute-based or phase-specific permissions must be implemented in business logic.
  • Admin scope creep: Overbroad admin roles can bypass org restrictions and should be constrained.

Practical Recommendations (Config & Testing)

  1. Enforce org filters via middleware: Inject currentTenant/currentOrg in request-scoped DI and auto-append filters at the ORM/query layer.
  2. Build a permissions matrix and automated tests: Add cross-tenant/org authorization test suites to CI that include positive/negative and lateral-movement attempts.
  3. Limit admin boundaries: Implement tiered admins and audit/approval workflows for super privileges.
  4. Audit & monitoring: Log tenant/org contexts for sensitive APIs and periodically scan for anomalous access patterns.

Important Notice: Entity-level isolation is necessary but not sufficient; it must be complemented by API/business-layer enforcement and ongoing testing.

Summary: The model provides a strong foundation for fine-grained permissions; reach production-grade security by combining middleware-enforced filters, permissions test suites, and audit monitoring.

85.0%
How should teams design deployment, CI/CD, and testing workflows to safely extend and operate Open Mercato?

Core Analysis

Core Question: To safely extend Open Mercato, CI/CD and test pipelines must validate module migration ordering, key management, index/event systems, and authorization end-to-end.

Technical Analysis (Key Processes)

  • Module migration orchestration: CI should resolve migration dependencies and apply them in topological order; rehearse cross-module migrations and rollbacks in staging.
  • Integration & auth testing: Auto test suite must include cross-module functional tests, RBAC positive/negative tests, and lateral-movement attempts.
  • Key management drills: Validate KMS/Vault integration, DEK rotation, and key-loss/recovery in non-prod.
  • Index & event E2E checks: Validate JSONB ↔ Meilisearch sync latency and subscriber persistence/replay (Redis/local).
  • AI/MCP control plane: Assign least-privilege service accounts, enable audit logs and rate limits for MCP API execution.

Practical Recommendations (Implementation Steps)

  1. Add migration metadata & CI validation: Declare depends_on in migrations and simulate ordered application in CI for PRs.
  2. Use staged deployments: dev -> staging (full E2E & key drills) -> canary -> prod. Run canary with real traffic and monitor crypto latency, index lag, and permission anomalies.
  3. Build permissions & lateral test library: Add minimal-permission, over-permission, and exploitation test cases for sensitive APIs in CI.
  4. Automate index consistency checks: Periodically validate Meilisearch/JSONB index vs DB records in CI/staging.
  5. Run disaster recovery drills: Regularly test key loss, index rebuilds, and DB rollback procedures and capture SLO/recovery metrics.

Important Notice: Never configure KMS or execute critical migrations for the first time in production—drill everything in staging with automated verification.

Summary: A CI/CD pipeline centered on migration dependency management, comprehensive auth tests, and key/index drills is essential to safely scale Open Mercato.

85.0%

✨ Highlights

  • Module-based auto-discovery and overlay overrides for easy extensibility
  • Built-in AI Assistant with MCP for schema discovery and API execution
  • SaaS-ready multi-tenancy with strict tenant and organization scoping
  • License and contributor details are unclear; exercise caution before adoption

🔧 Engineering

  • Declarative custom entities and dynamic forms manageable at runtime
  • Field-level encryption with tenant-scoped DEKs, balancing compliance and performance
  • Modular monorepo with per-module migrations to enable parallel team development
  • Integrated modern stack (Next.js/TypeScript/zod/Awilix/MikroORM)

⚠️ Risks

  • Repository license is missing—legal uncertainty for commercial use and redistribution
  • Very few contributors and no releases—high risk for community activity and long-term maintenance
  • Rich feature set implies non-trivial learning curve and integration effort

👥 For who?

  • SaaS vendors and product teams needing rapid delivery of customizable enterprise apps
  • Enterprises requiring multi-tenant isolation and field-level encryption for compliance
  • Development teams capable of front/backend collaboration and willing to maintain custom modules