Skip to main content

Extending the Hub

The Hub ships with a curated stack out of the box. Two routes exist for going beyond that, each addressing a different audience:

  1. 6ix Labs catalog — built by 6ix Labs, signed, available in every Hub install.
  2. Enterprise API — a documented API + SDK; the enterprise customer builds their own integrations against it, on a subscription.

There is no third-party application or community-contribution route. The Hub is a closed, single-vendor ecosystem.

:::note Status On the roadmap. Not yet implemented. This page describes the planned design. :::

Tier 1 — 6ix Labs catalog​

Every package in the catalog is built and maintained by 6ix Labs. We pick what to integrate based on customer demand, ship it, sign it, support it, version it alongside Hub releases. Some are bundled with the Hub license; others are paid add-ons.

Likely catalog (priority/order TBD, not a commitment):

  • Vector stores — Weaviate, Pinecone, MongoDB Atlas Vector, pgvector, Chroma (alongside the bundled Qdrant)
  • Model servers — TGI, NVIDIA Triton, Ollama, llama.cpp (alongside the bundled vLLM)
  • Dev tools — JupyterHub, VS Code Server, RStudio Server
  • Workflow — Airflow, Prefect, Dagster
  • Observability add-ons — Sentry, Datadog Agent, OpenTelemetry collector
  • RAG / agent frameworks — LangChain server, LlamaIndex server, Haystack

Every catalog package is signed by 6ix Labs. The Hub refuses to install unsigned packages in this tier.

Format & safety rails​

A catalog package is a directory (or signed tarball) with:

  • package.yaml — metadata: name, version, category, license, homepage, minimum_hub_version.
  • compose.yaml — docker-compose service. Must declare ports, healthcheck, mem_limit, cpus, volume mounts (constrained to /var/lib/hub-packages/<name>/).
  • manifest.json — UI manifest: icon SVG, default settings form, log viewer hints.
  • signature.sig — 6ix Labs signature on the package contents.

Safety rails enforced on every package:

  • Resource caps (mem_limit, cpus, pids_limit) — cannot be bypassed.
  • Network egress disabled by default; outbound hosts declared in package.yaml, opt-in by the user.
  • Filesystem confined to /var/lib/hub-packages/<name>/; no host docker socket, no /proc, no /sys.
  • cap_drop: ALL + no-new-privileges — cannot escalate.
  • Every install / update / removal in the audit log.
  • One-click rollback.

Tier 2 — Enterprise API​

For Enterprise-tier customers who want to integrate their own internal services with the Hub without waiting on 6ix Labs to ship a catalog package.

Instead of submitting compose files for us to review, customers build against a documented API + SDK that exposes the Hub's service-registry, observability bus, audit log, and lifecycle hooks. Their integration lives in their codebase, on their schedule, under their control.

This route is paid: a per-seat or per-call API service fee on top of the Enterprise Hub license. It buys access to the API, an SDK, OpenAPI spec, and standard-tier support for integration questions.

What the API exposes​

  • Service registration — register a service running anywhere the customer chooses (their own container on the Hub, a remote machine, a cloud endpoint). The Hub surfaces it in the Containers / Telemetry pages.
  • Observability bus — push metrics, logs, alerts into the Hub's Prometheus / Grafana / Loki stack. Read existing metrics for correlation.
  • Audit log — write structured events for the customer's own services so they show up in the Hub's audit trail alongside Hub-native events.
  • Lifecycle hooks — react to Hub events (model loaded, scan completed, backup ran, container failed) via webhook or signed event stream.
  • Storage — namespaced read/write to /var/lib/hub-api/<tenant>/ for the customer's integration state.
  • Auth — federate with the customer's identity provider (OIDC / SAML) so their staff get role-based access to the Hub.

What the API does not expose​

  • Host-level shell access. Never.
  • The internals of 6ix Labs catalog packages.
  • The HIFF / GRIFF-Δ engine source. The engine is consumable via a scored-response API on Δ UI Enterprise — but the algorithm itself is not exposed.
  • Permission to bypass the safety rails.

Why this approach​

The honest reason: building bespoke integrations for every customer doesn't scale. The 6ix Labs catalog (Tier 1) covers the high-demand packages everyone wants. The Enterprise API (Tier 2) lets sophisticated customers integrate what they need themselves, on a paid subscription, without us being the bottleneck.

What's NOT on the roadmap​

  • A community-contributed package system.
  • A vendor application program where third parties submit packages for review.
  • Open-sourcing the Hub, Δ UI, Corpus, or HIFF / GRIFF-Δ.
  • Any path for someone outside 6ix Labs or our Enterprise customers to ship code into the Hub.

This is a closed, single-vendor ecosystem by design — Tesla / Sonos model, not Linux distro.

Requesting a catalog package​

If you'd benefit from a catalog package that doesn't exist yet, email support@6ixlabs.ai with the subject "Package request:". Tell us what you want, why, and how urgent. We prioritise by aggregate demand. If you're an Enterprise customer interested in API access, email the same address with the subject "Enterprise API:".