Show HN: Hexis, open-source Claude Skills management

Bevel Software released Hexis, an open-source, git-backed control plane for managing AI-agent skills, tools, context, permissions, and identity, self-hosted and MCP-native. The platform allows centralized management of AI plugins and knowledge, with every skill and permission stored as files in a git repository for auditability, and integrates with Claude and Cline via MCP. Hexis is available as a public demo at demo.bevel.software and can be deployed via Docker.

Git-backed control plane for AI-agent skills, tools, context, permissions and identity. Self-hosted and MCP-native. One place where your company's AI plugins, tools and knowledge live: centrally managed, reviewed and access-controlled, and usable from any AI agent . The open-source core of the Bevel platform. One place where engineers and non-technical people alike can browse and load plugins, propose suggestions, and manage access. Every skill, tool manual and permission is a file in a git repository you own, so the audit trail is the storage layer: who changed what, when, who approved it, and how to undo it. An agent can only do what the person running it can do, resolved per file, and it never holds the credentials it uses. Runs on your infrastructure, behind your own SSO. A gateway decides which tools an agent may call. It has no opinion on whether the skill telling that agent what to do is any good. In Hexis, skills and tool manuals are reviewable files. Anyone can propose a change; on protected branches it reaches the owners of the files it touches and ships only once they approve. Agents propose too: one that hits a broken skill mid-task can suggest the fix, and a person decides whether it lands. See Hexis in action see-hexis-in-action Connect Hexis to Cline connect-hexis-to-cline Try the live demo try-it-first-the-live-demo Managed hosting want-a-managed-instance Deploy with Docker deploy-it-in-5-minutes-docker Local development local-development-run-from-source Configuration reference /Bevel-Software/Hexis/blob/main/docs/configuration.md Troubleshooting /Bevel-Software/Hexis/blob/main/docs/troubleshooting.md Repository layout repository-layout FAQ faq Watch the full walkthrough: connect an agent, use company context, review proposed changes, and manage team access. Anyone can propose a new skill or improve an existing one. On protected branches, owners review the exact change and approve it before it becomes available to the team's agents. Connect Claude to Hexis over MCP, then ask normally. Claude can discover and load the approved skill instructions and company context your role can access, without copying prompts between tools. Cline can connect directly to Hexis as a remote Streamable HTTP MCP server. Install the public demo connection from the Cline CLI: cline mcp install hexis --transport http https://demo.bevel.software/api/mcp --yes Complete the OAuth sign-in in your browser when prompted. Cline then discovers the skills, tools and context your Hexis role can access. For your own Hexis deployment, replace demo.bevel.software with your deployment's host. Add teammates to roles or grant access directly when needed. Everyone connects to the same workspace, while each person and their agent only sees what they are allowed to read. demo.bevel.software is a public instance you can sign into with your Google account, populated with a fictional company's knowledge, skills and tools. The Start here page walks you through the whole loop: connect your own agent over MCP, have it build a sales deck from a skill, watch its proposed improvement arrive as a change request. The demo is shared and read-mostly visitors propose, owners approve ; everything below gets you the same thing with none of the limits. We run it for you hosting, upgrades, backups, SSO and your team just signs in. Write to ali.raza@bevel.software . You need: Docker https://docs.docker.com/get-docker/ with Compose on a server or your laptop; one line below differs , and an empty git repository on any host GitHub, GitLab, Bitbucket, Azure DevOps, self-hosted to hold your knowledge base. The app seeds it with a starter template on first run. git clone https://github.com/Bevel-Software/Hexis.git cd Hexis cp .env.example .env Open .env and fill in the four required values everything else can wait : ADMIN EMAIL=you@example.com the deployment owner, always an admin ADMIN PASSWORD=pick-something sign-in password; only with password login SSO-only deployments drop it JWT SECRET=… generate with the command below SECRETS ENC KEY=… generate with the command below Generate the two secrets run twice, paste one result into each : js node -e "console.log require 'crypto' .randomBytes 32 .toString 'base64' " no Node installed? docker run --rm node:22-slim node -e "console.log require 'crypto' .randomBytes 32 .toString 'base64' " For a public deployment, also set the origin values: PUBLIC BACKEND URL=https://bevel.your-domain.com public origin; OAuth redirects are built from it PUBLIC FRONTEND URL=https://bevel.your-domain.com same origin: the backend serves the SPA Then start everything Postgres + the app . Behind a reverse proxy Coolify, Traefik, nginx; recommended : docker compose -f docker-compose.yml up -d Also set TRUST PROXY to your proxy hop count 1 for a single proxy , so rate limits see real client IPs instead of the proxy's. The explicit -f skips docker-compose.override.yml , so the app publishes no host port : your proxy reaches it on port 3001 over the compose network. This is deliberate: a fixed published port makes every redeploy fail with port is already allocated , because the replacement container starts while the outgoing one still holds it. Directly exposed no proxy : plain docker compose up -d publishes :3001 ; use APP PORT=8080 docker compose up -d for a different host port. Leave TRUST PROXY unset here. With no proxy in front, trusting forwarded headers would let clients spoof their own address. Open your domain and sign in with ADMIN EMAIL / ADMIN PASSWORD . Just trying it on your laptop? Same steps, minus the origin values: plain docker compose up -d , then open http://localhost:3001 . The app asks for the things it could not guess, and tests them against the real host before saving : Knowledge-base repo : the https clone URL of that empty repository. Git credential : a token with read/write access to it for GitHub: a fine-grained personal access token with Contents: read & write on that one repo is enough . Branch model : which branch is the default and which are protected changes to protected branches only land through approved change requests . The repository's real branches are offered as suggestions; for an empty repo the default main is fine. Since the repo is empty, the app initialises it from the bundled template and writes a roles.yaml whose first Admin is you. That's it: you're in the workspace. Head to Skills & Tools to make your first plugin and skill, and to Connect in the app menu to hook up an agent over MCP. Going to production? Configuration reference /Bevel-Software/Hexis/blob/main/docs/configuration.md covers single sign-on, the state you need to back up, health checks, and configuring by environment instead of the setup screen. You need: Node 22 .nvmrc ; the engine range is =22 <23 , pnpm 10 , git ≥ 2.41 , and a Postgres 17 the bundled one is fine : docker compose up -d db just the database pnpm install pnpm build builds the packages the apps import cp .env.example .env fill the same four required values; the default DATABASE URL already points at the bundled db pnpm dev backend on :3001, Vite dev server on :5173 Open http://localhost:5173 the dev server proxies to the backend . Useful commands: pnpm test , pnpm typecheck , pnpm lint .Migrations run automatically on boot; there is no separate migrate step, in dev or in production. : every environment variable, SSO setup, secret generation, backups and health. Configuration /Bevel-Software/Hexis/blob/main/docs/configuration.md : the failures you are most likely to hit, and what causes them. Troubleshooting /Bevel-Software/Hexis/blob/main/docs/troubleshooting.md | Path | What it is | |---|---| packages/shared | @bevel-software/platform-shared : shared types + pure domain utilities | packages/core-backend | @bevel-software/platform-core-backend : the core backend ships migrations/ + kb-template/ | packages/core-frontend | @bevel-software/platform-core-frontend : the core UI, published as raw TS/TSX source | apps/server | standalone core backend shell | apps/web | standalone core SPA shell Vite | Questions that come up when teams evaluate Hexis as a central, versioned catalogue for agent skills and tools. How do agents find skills without flooding the context window? They look them up rather than loading them all: list skills and search narrow the field, get skill returns one skill at call time. Which agents can connect? Any MCP-capable client, including Claude Code, Codex, Cursor, Cline and ChatGPT, each seeing only what its user's role allows. How is the catalogue versioned? By git: every save is a commit, so history, blame and revert work as they do for code, and changes to protected branches ship as reviewable change requests. What governance do we get? Per-file access control, review-gated change requests, and a git audit trail of who changed what and who approved it. License: Apache-2.0 /Bevel-Software/Hexis/blob/main/LICENSE