HiMarket: turning scattered AI assets into a governed internal marketplace

What the project is actually trying to fix

The README opens with a list of problems rather than a feature list, which tells you the product's real motivation. Enterprises scaling their AI adoption hit four recurring walls: model usage fragmented across teams, security exposure from uncontrolled access to public model endpoints, no way to measure AI cost or service level, and permission management that grows more tangled with every team added.

HiMarket's answer is a unified entry point for the whole organization, built on the Higress AI Gateway, where AI producers and consumers meet through a standardized marketplace. The README is explicit that this is not a plain aggregation of existing APIs. Distributed AI capabilities get packaged, published, managed and operated as standardized API products, with multi-version management and gray-scale release as first-class features rather than afterthoughts.

The claim to take seriously is the packaging. Turning a raw model endpoint or an MCP Server into a product with versions, quotas, authentication and approval is unglamorous work, and it is the work that decides whether an internal AI platform survives contact with a real security review.

Five marketplace types and two experience surfaces

The capability table divides into four groups. The AI Marketplace carries a Model Marketplace for models with content safety and token rate limiting, an MCP Marketplace that can convert external APIs into standard MCP Servers, an Agent Marketplace for packaged agent applications integrated with AgentScope and similar build platforms, a Skills Marketplace where developers browse and install Agent Skill packages, and a Worker Marketplace for versioned agent Workers that load with Skills, supporting Nacos batch import and CLI installation.

The AI Experience Center adds two interactive surfaces rather than another list row. HiChat handles single-model conversation, side-by-side multi-model comparison, MCP tool invocation testing and web-connected question answering. HiCoding offers online programming inside a secure sandbox, positioned for vibe coding and human-AI pair work with real-time file changes and code preview.

The Enterprise Management and Customization groups are where this stops being a developer tool: product management with authentication, traffic control and call quotas; observability with full-chain monitoring, call tracing, heatmaps and anomaly alerts; token-based metering with automatic cost statistics; portal branding with a custom domain and layout; third-party OIDC integration; and a configurable approval workflow for subscriptions and product access.

Three layers, and what the repository tree reveals

The architecture section describes three layers. Infrastructure is composed of the AI Gateway, API Gateway, Higress and Nacos, with HiMarket abstracting those into standard API products. Above that sits the admin platform, where administrators create and customize portals, manage AI resources and set authentication policies and subscription approval workflows, with an observability dashboard. The third layer is the developer-facing portal, also called the AI Marketplace or AI Hub, where developers register, apply for credentials, browse and subscribe to products, debug online, and use HiChat or HiCoding.

The repository tree matches that layering more or less one to one. `himarket-server/` and `himarket-dal/` are the Java service and data access layers, `himarket-web/` holds the front ends, `himarket-bootstrap/` is the assembly module the Makefile compiles, and `harness/` sits alongside `sandbox/` for agent runtime work. Supporting directories include `deploy/`, `docs/`, `scripts/` and an `OPEN_SOURCE_BACKEND_OPTIMIZATION_LOG.md`.

Two entries deserve a second look because they say something about how this project is built and consumed: `.agent-skills/`, `.claude/` and `.codex/` at the root, and `AGENTS.md` with a Chinese counterpart. The project ships its own agent configuration alongside its product, which is an unusual thing to find in a repository root and hints that part of the development workflow runs through coding agents.

Getting it running locally takes five environment variables

The README's local setup path is honest about its requirements: JDK 17, Node.js 18+, Maven 3.6+ and MySQL 8.0+. Database connection goes into `~/.env` or is exported directly, and the variable names are the obvious ones:

export DB_HOST=localhost
export DB_PORT=3306
export DB_NAME=himarket
export DB_USERNAME=root
export DB_PASSWORD=your_password

The backend then comes up with a single command, which the README describes as compiling, stopping old processes, starting in the background and waiting until the service is ready, with the API landing on port 8080:

make run

The front end is a separate process per portal, each with its own dev port. The admin portal is the first one:

cd himarket-web/himarket-admin
npm install
npm run dev

Two ports rather than one for the two front ends is worth noting, because it confirms the admin console and the developer portal are separate applications rather than one app with a role switch.

The Makefile is the clearest window into the build

The repository includes a full `Makefile`, and it is more informative than a typical wrapper because every target maps to a concrete Maven invocation. The fast compile path skips tests and the Spotless check, which tells you the project runs a format gate as part of its build:

./mvnw -pl himarket-bootstrap -am package -DskipTests -Dspotless.check.skip=true -q
./mvnw clean verify
./mvnw test
./mvnw spotless:check

There is a separate integration test target that filters by group, and a lint-fix target that applies formatting rather than only reporting it. That combination, a wrapper Maven binary (`mvnw` and `mvnw.cmd`), a `.mvn/` directory and a `.husky/` directory, describes a Java shop with enforced style and pre-commit hooks rather than an informal open-source project.

The wrapper being used everywhere is also a practical detail. Maven 3.6+ is listed as a requirement, yet every target calls `./mvnw`, so the effective requirement is a JDK and a shell rather than a specific Maven install.

Release notes show where the effort is going

The three most recent releases describe a product being actively reworked rather than maintained. v0.8.0, published on 2026-08-14, is framed as a major HiChat and developer portal release: HiChat moves to AgentScope Java 2.0 and HarnessAgent with persistent agent state, bounded context rebuilding and MCP runtime state synchronization, and streaming gets ordered `messageChunks` for thinking, text, tool calls, tool results and generated images while keeping the plain `answer` as a compact fallback. The same release adds OpenAI-compatible and DashScope image generation and editing, and raises Skill and Worker package upload limits from 10 MB to 30 MB.

The two earlier releases are narrower and more revealing about the operational reality. v0.7.6 fixed vertical scrolling in the Skill and Worker detail panels and, more interestingly, isolated metadata synchronization failures by registry instance so that an unavailable Nacos or AIRegistry endpoint no longer blocks updates for other products. It also removed per-product remote metadata lookups from the marketplace listing in favour of locally synchronized metadata, which is a straightforward admission that remote calls on a list page do not scale.

v0.7.5 hardened the admin side: it prevented repeated or malicious administrator initialization when an admin account already exists, and enforced exclusive AIRegistry Skill bindings based on package `SKILL.md` names while protecting historical shared bindings. A project that fixes admin bootstrap abuse in a minor release is a project with real enterprise deployments behind it.

Editorial conclusion

HiMarket is worth reading for anyone who has watched a company accumulate model endpoints faster than it can govern them, because the problems it names are real and its answer is a product abstraction rather than a proxy config. The five marketplace types, the split between an admin console and a developer portal, and the metering and approval features are the parts that transfer to any environment, including self-hosted. What the repository does not give you is a sense of cost: the gateway stack, MySQL, Nacos and a sandbox runtime all have to exist before anything works. Read the deployment guide at higress.io/docs/himarket/himarket-deployment first, then run `make run` locally with the five database environment variables set, and judge the product model against your own approval requirements before you commit to the stack.

Frequently asked questions

Official sources

1. higress-group/himarket on GitHub
2. Issues
3. README
4. Releases