Open-source software factory

Jumentix

The Jumentix mark comes from the Brazilian jegue: steady, practical, resilient. The platform carries enterprise Node.js architecture from the first modular monolith to an unlimited service landscape.

The animal is the promise: less ceremony, more load-bearing software.

Start building Explore the platform

99% quality threshold
DDD + Hexagonal
Bun monorepo
Open source

Jumentix carries the load

A practical mascot for practical architecture

The jegue is part of the product language: dependable movement, strong footing, and no drama when the terrain changes. Jumentix applies that to visual domain design, contract-first runtimes, reusable adapters, developer automation, and deployment governance.

12+HTTP and function adapters

10+persistence targets

3API interface styles

99%coverage standard

Architecture you can see

Design bounded contexts as a living system

The Domain Designer turns domains, entities, fields, validation, and relationships into a navigable model. The same contracts guide code generation and API documentation.

See the product Architecture docs

Jumentix Domain Designer displaying bounded contexts and entity relationships — The Domain Designer as it ships today.

Code is part of the product

Start locally. Keep every production option open.

The same application contracts work across a modular monolith, realtime server, functions, and distributed services.

npx @jumentix/cli-init init my-product
cd my-product
bun install
bun run dev

Bun-powered tooling

The fast path is the default path

Every project the Jumentix CLI generates runs on Bun: one pinned tool is the runtime, package manager, script runner and test runner, so your laptop and your CI run the same thing.

Why Bun matters here

Bun removes the setup a new project usually needs: workspaces install fast, TypeScript runs without a build step in development, and one set of scripts covers every app in the project.

Generated projects pin `bun@1.4.2` in `packageManager`, so every machine runs the same version.
`bun run dev`, `test`, `lint` and `build` run across every app in the workspace.
Backend services start straight from TypeScript source in development.
`jumentix add`, `upgrade` and `doctor` keep the project growing and current after the first day.

CLI reference Bun docs

npx @jumentix/cli-init init my-product --mode=hybrid
cd my-product
bun install
bun run dev

1runtime/package/test/bundle tool

1.4.2+pinned Bun version

4CLI commands: init, add, upgrade, doctor

14xfaster cold install vs npm, measured on this monorepo

Fails loud, not silent

`bun run --filter` exits 1 when no workspace matches. The pnpm `--if-present` equivalent exited 0 and produced a false green here before.

--filter exit 1

No build step in development

Backend services start straight from TypeScript source — nothing to recompile before you run or test a change.

no tsc step

Installs with zero flags

This monorepo installs clean on Bun. The same tree needs `--legacy-peer-deps` to even resolve under npm.

zero install flags

Understands `workspace:*` natively

npm refuses this tree outright — an unsupported-protocol error — until every `workspace:*` range is rewritten by hand.

workspace:*

A lockfile you can actually review

`bun.lock` is committed as readable text, so a dependency change shows up as a real diff in code review.

bun.lock (text)

Native test runner, already measured

`bun test`: 1.72s for 531 tests. Jest: roughly 28s for the same suites.

bun test 1.72s/531

Bundler included

Package builds ship real ESM bundles with no separate webpack, rollup or esbuild dependency — bundling costs single-digit milliseconds.

bun build

One tool, not four

Runtime, package manager, bundler and test runner pinned together — the alternative is four tools that can silently drift out of sync with each other.

1 pinned tool

One version pin ends "works on my machine"

`.bun-version`, `packageManager` and `engines.bun` are enforced together — a version mismatch fails the install, not the deploy.

.bun-version

Quality as product surface

Requirements, tests and evidence are not hidden plumbing

Jumentix treats quality as part of the user-facing promise. Requirements are checked, tests are mapped, architecture rules are executable, and publish paths carry evidence instead of relying on ceremony.

98%minimum statement, branch, function and line coverage

reqsrequirements tied to executable checks

0tolerance for hidden docs drift

realbrowser tests for browser APIs

Requirement registry

Delivery work is expected to connect behavior, docs, tests and release evidence so “done” is auditable.

requirements:check

Reliable tests

Unit, integration, Cypress route sweeps, browser specs and Storybook smoke checks cover the surface each layer actually owns.

test-map:check

Executable architecture

Boundary scripts reject imports and shortcuts that would leak frameworks, databases or infrastructure into domain code.

arch:check-*

Publish discipline

Content sync, route checks, package dry-runs and release governance run before public artifacts move.

website:test:prepublish

bun run requirements:check
bun run test-map:check
bun run docs:check-audience
bun run website:test:prepublish

AI-ready platform

The UI gives agents architecture with governance attached

Jumentix is prepared for AI because the product does not ask agents to infer architecture from scattered code. The UI captures bounded contexts, entities, interfaces, deployment profiles and requirements; the repository exposes agent-readable docs and executable checks that keep generated work accountable.

UIdomain model as first-class input

llmsagent-readable website context

reqsrequirements tied to checks

gatesarchitecture and publish evidence

1. Model service

UI captures the domain

Category, Task, relationships, validations and API surfaces become explicit platform data.

2. Ground the agent

Docs and packages name the path

The agent reads the docs index, package contracts and UI blueprint before choosing files to change.

3. Generate inside boundaries

Ports and adapters shape the code

Use-cases, controllers, SDK clients, Cana examples and runtime profiles keep their ownership boundaries.

4. Verify evidence

Governance checks catch drift

Requirements, test maps, architecture scripts, route checks and prepublish gates validate the change.

5. Publish with confidence

PR carries proof

Reviewers see what changed, why it fits the architecture and which checks prove it is ready.

Low-context instructions

Agents can start from docs index, package pages, route metadata and code snippets instead of guessing which file owns a behavior.

/llms-full.txt

UI as architecture input

The Service Management UI turns product concepts into bounded contexts, interfaces and deployment choices that generators and reviewers can inspect.

service-management-ui

Governed generation

Generated or agent-authored changes still pass requirements, test maps, route checks, package boundaries and release governance before publication.

requirements:check

Grounded package graph

Reusable packages give AI work stable names for persistence, mediation, clients, Cana, runtime bootstrap and architecture boundaries.

packages/*

AI work becomes governed delivery

The UI gives AI a constrained starting point: the service vocabulary, boundaries, interfaces, runtime profile and quality obligations are explicit before a prompt is written. That turns the agent from a code guesser into a contributor working inside the platform rules.

Prompts reference named bounded contexts, entities, requirements and packages instead of broad implementation wishes.
Generated code has a known landing zone: UI model, contracts, SDKs, use-cases, adapters, tests and docs.
Reviewers can reject drift with executable checks instead of relying only on manual architecture review.

AI action	UI source	Governance guardrail	Useful output
Design safely	Bounded context, entities, relationships and requirements.	Service model validation and requirement registry.	A service spec that product, architecture and engineering can review together.
Generate safely	Interfaces, events, deployment profile and package choices.	OpenAPI, AsyncAPI, route checks and workspace boundaries.	Contracts, SDKs, handlers and examples aligned to the same model.
Ship with evidence	Quality expectations, release path and docs index.	Test map, architecture checks, docs sync and prepublish gates.	A PR reviewers can audit with concrete proof instead of narrative confidence.

{
  "boundedContext": "Tasks",
  "entities": [
    { "name": "Category", "fields": ["id", "name", "color"] },
    { "name": "Task", "fields": ["id", "title", "categoryId", "completed"] }
  ],
  "interfaces": ["REST", "WebSocket"],
  "deploymentProfiles": ["dev", "staging", "production"],
  "requirements": ["REQ-TASK-CATEGORY", "REQ-TASK-LIVE-UPDATES"],
  "governanceChecks": [
    "requirements:check",
    "test-map:check",
    "arch:check-workspace-boundaries"
  ]
}

Choose a delivery path

Jumentix is for teams that want framework speed without surrendering domain ownership, portability, or operational evidence.

Build the product. Keep the architecture.

Explore the source, run the factory locally, and turn your next Node.js service into a repeatable platform capability.

Read the docs GitHub