MonoX

Monorepo generator ו-delivery contracts

מייצרים את המוצר ואת ה-delivery path ביחד.

פקודה אחת כותבת workspaces ל-web, API ו-worker, מגדירה dependency boundaries, מחברת local services, CI ו-containers, ונותנת מסלול ברור ל-PM2, Coolify או Kubernetes. המפתחים וה-coding agents עובדים מול אותו contract בכל package.

מתחילים עם 0.2 רואים את הקוד

מה הפקודה באמת כותבת

Repo עם מקום ברור לקוד של המוצר, לקוד reusable ול-infra

ה-recipes מגיעים bundled ו-versioned. הקובץ monox.lock שומר version ו-integrity, כדי שגם במחשב אחר יהיה ברור בדיוק מה יצר את המבנה. 

my-product/
├── apps/
│   ├── api/
│   ├── jobs/
│   └── web/
├── packages/
├── infra/
│   ├── docker/
│   └── local/
├── .github/workflows/ci.yml
├── AGENTS.md
├── monox.config.json
└── monox.lock

Source of truth אחד לכל app

"deployment": {
  "schemaVersion": "2",
  "id": "jobs",
  "kind": "worker",
  "network": { "exposure": "none" },
  "env": { "secretRefs": [{
    "name": "rabbitmq-url",
    "target": "RABBITMQ_URL" }] },
  "scaling": {
    "mode": "keda",
    "minReplicas": 0,
    "metrics": [{ "type": "rabbitmq",
      "sourceRef": "RABBITMQ_URL",
      "queue": "jobs", "target": 10 }]
  }
}

ה-root config מחזיק environments, targets ו-boundaries. אין בו רשימת applications כפולה.

ה-setup ש-MonoX מוריד מהדרך

מה כבר לא צריך לחבר ידנית

MonoX אורז את החלטות הפלטפורמה שחוזרות בכל פרויקט. החלטות המוצר עדיין נשארות אצלכם.

  1. 01

    Workspace setup

    Package manager, workspace globs, dependency direction ו-boundaries משותפים ל-agents.

  2. 02

    Local runtime

    Health routes, קבצי Docker ושירותים שבחרתם, עם placeholders שחייבים למלא בקובץ local ignored.

  3. 03

    Verification

    Immutable install, בדיקת lock, פקודות test ו-build בתוך ה-CI שנוצר.

  4. 04

    Delivery model

    Workloads typed, probes, limits, scaling signals ו-plan שמותאם ל-target.

מ-local עד production

ה-contract נשאר קבוע, ה-target מתחלף

ה-package מתאר את ה-workload. ה-target שבחרתם משלים image, namespace, domain, identity ו-secret bindings.

  1. Validateעוצר unknown fields, inline secrets ו-targets לא חד משמעיים.
  2. Explainמראה את ה-defaults, ה-profile, ה-environment וה-variant לפי הסדר.
  3. Planקושר source, config, target state ו-adapter digests.
  4. Applyרץ דרך ה-local executor המובנה או transport שמחובר במפורש, ודוחה plan לא עדכני.

הגבול של 0.2.0: create-monox כותב את ה-contracts האלה, אבל עדיין לא מתקין monox delivery binary ציבורי. הפקודות למטה הן tooling מתוך ה-source repo, לא פקודות שמגיעות בתוך הפרויקט שנוצר. 

# MonoX source checkout
yarn monox validate
yarn monox config explain @monox/jobs --env staging
yarn monox plan --env staging --all --output .monox/plan.json
yarn monox apply --plan .monox/plan.json

MonoX מגדיר את הגבול. אתם אחראים למה שעובר דרכו.

אתם מספקים cloud access דרך OIDC או workload identity, בוחרים domains ו-managed services, מגדירים budgets ו-capacity, מחברים external secrets ומאשרים שינויים ב-production.

MonoX לא מחליף cloud control plane, לא מבטיח capacity אצל ה-provider ולא מחביא פעולות destructive בתוך deploy רגיל.

הוכחות של release 0.2

מה כבר ממומש, מה guarded ומה עדיין מחכה ל-production proof

הסטטוס מחובר לטסטים ב-repo הציבורי. Claims עתידיים נשארים בחוץ עד שיש להם הוכחה.

Surface סטטוס release הוכחה
Deployment contract v2 ממומש Package discovery, RFC 7396 overlays, variants ו-target binding יחיד
Workspace recipes Built in Catalog ל-JavaScript, TypeScript, Python, PHP ו-Go עם deterministic locks
Local ו-container path נבדק ב-source Compose contracts ו-non-root defaults; runtime acceptance מלא לכל ה-add-ons עדיין פתוח
PM2, SSH, Coolify ו-Kubernetes Guarded Typed plans ו-fail-closed transport injection לפני שינוי חיצוני
AWS ו-GCP provisioning Plan only ב-0.2.0 נוצרים provider plans בלבד; real sandbox apply לא כלול
Production reference עוד לא פומבי 42 contracts tracked עברו inventory; ה-case study מחכה ל-security cleanup ול-canary rollback