Self-hosting

The public repository contains the dashboard, reporting API, owner MCP, docs, attachments and issue/reply loop. It runs independently of Hivenet's company website.

Try it locallyCopy Anchor Link

With Node 22.12 or later, Corepack and pnpm installed, run:

git clone https://github.com/zvadaadam/hivenet.git
cd hivenet
pnpm install --frozen-lockfile
pnpm dev

Open the printed URL. The local fixture signs in as dev@localhost; create a project and send a report to its local endpoint. No WorkOS or company credentials are needed in this mode. The CLI's default registry is the hosted service, so use your installation's generated DSN or explicit endpoint for reports to your instance.

Deploy your instanceCopy Anchor Link

The full application uses Cloudflare Workers, D1 and R2. Production sign-in currently requires your own WorkOS AuthKit project. Development authentication is disabled in production builds.

Follow the deployment guide to create resources, generate your configuration, set authentication secrets, and validate the Worker bundle before deployment. Your instance's docs and agent-readable links use its origin.

For an ingest endpoint without a dashboard, WorkOS or attachments, use the smaller packages/server reference implementation.

Use the CLI with your serverCopy Anchor Link

Use the official client with your own instance; you do not need to publish another CLI. CLI/SDK 0.7.0 or later supports an explicit registry:

npx --yes hivenet@^0.7.0 doctor --registry https://feedback.example.com --to my-project --smoke
npx --yes hivenet@^0.7.0 --registry https://feedback.example.com --to my-project "Testing my installation"

Replace the origin and slug with yours, or copy the complete command from Integration. The doctor report appears under Events → Spam and creates no issue or notification. The second command sends a real report. Follow-up commands keep the server address.

A bare --to my-project uses Hivenet's hosted registry by default. With --registry, the server and slug are explicit and take priority over local environment/configuration destinations. --dsn still takes priority over both. HIVENET_REGISTRY changes the default registry for a shell; it does not override a DSN or an endpoint in feedback.config.json.

If a custom ingest endpoint is configured only in feedback.config.json, run copied CLI follow-ups from the same directory hierarchy. They reuse that file's exact endpoint and optional write key without requiring a registry.

Older clients can use --dsn "<DSN from your instance>". The DSN is write-only and publishable; your separate owner secret must never go in reporter instructions. For owner CLI access, set HIVENET_SECRET_KEY securely and run npx hivenet inbox --api https://feedback.example.com. Owner MCP uses your origin's /mcp, and reporting MCP uses /mcp/submit.

Forking and publishingCopy Anchor Link

A fork can build and deploy the whole product with its own provider accounts. Public CI does not deploy Hivenet's hosted site, and the official npm publishing job skips forks. A copied workflow grants no rights to publish the official package.

Most self-hosters use the official CLI unchanged. If you modify and distribute the CLI, use your own npm package, such as @acme/hivenet, repository metadata and trusted publisher. Update your generated snippets if they should install that package. The fork and release guide covers this separately from deploying an instance.

Publish the matching CLI before deploying an app that generates commands requiring it. The instance-aware commands above require 0.7.0; app deployment and npm publication are independent.