manifold
manifold is an API-only adoption profiler for self-managed GitLab. I build and maintain it at GitLab Public Sector, the same group behind egress‘s outbound-connection catalog for self-managed GitLab. Point it at a customer’s own self-managed GitLab instance and it reads activity through the GitLab REST API, scores it, and renders an interactive dashboard of who uses which features, where the adoption gaps sit, and which enablement action, a workshop or a play, closes each one. I built it because I don’t often get to meet the development teams behind the offline customers I support, so the instance’s own activity has to introduce them. It gives a platform operator a way to characterize the archetypes and the influential, active people on an instance, the ones worth reaching first for strategic enablement. And it has to do that without touching the customer’s database or ever leaving their network: the API call is the entire surface. A companion site, manifold-demo, renders the same dashboard from a synthetic seeded instance, so a reviewer can see what the tool produces before pointing it at a real one.
The pipeline itself runs in four stages: collect, analyze, render, pages. All four are defined once in deploy.yml, which a customer copies in as their own .gitlab-ci.yml and runs on a weekly CI/CD schedule, or triggers locally in one shot with the run subcommand. Each stage is also reachable on its own as a subcommand of the single cmd/manifold Go binary, including serve for a local dashboard preview.
The Influence view of that demo shows the shape of the output: the instance’s most influential users ranked and tagged by archetype, and the ego network of whoever is selected.

manifold is built for GitLab Public Sector’s own customer engagements, not for broad external adoption.