GitLab activity on your DevOps portfolio.

GitLab exposes two main APIs for reading public activity. The REST API v4 events endpoint at /users/:id/events and /groups/:id/events returns a paginated stream of recent events (PushedEvent, MergeRequestEvent, IssueEvent, ApprovedEvent, CommentEvent, AcceptedEvent for merged MRs). It is freely accessible for public projects without authentication and rate-limited to 2,000 requests per hour per IP on gitlab.com, which is enough for most widgets that cache responses. The GraphQL API is required for richer data: pipeline state, MR approvals, CI variables, and group-level aggregations. Both APIs work identically against gitlab.com and self-managed instances, which means a widget written once works for an indie maintainer with a public project and an enterprise team behind a VPN. A serious GitLab widget uses both: REST for events, GraphQL for pipeline state and group queries. Poper does exactly this, caches responses on a global edge so your visitors never hit GitLab directly, and refreshes from origin every 6 hours on Free or 30 minutes on Pro. Conditional requests with ETag headers mean we only pull fresh data when something actually changed.

GitLab is the only major source-control platform where the canonical deployment is self-managed. Roughly two thirds of GitLab's revenue comes from self-managed installations running inside customer VPCs, on bare metal in regulated industries, or in air-gapped environments for defense and intelligence customers. The free Community Edition is MIT-licensed and identical in core to the paid Premium and Ultimate tiers, which sells additional features around security scanning, compliance, and value stream analytics. This deployment model creates a real problem for portfolios: the typical DevOps engineer's best work lives on a self-managed GitLab behind a VPN that the public internet cannot see. A traditional GitHub-style widget that scrapes a public profile simply does not work. Poper solves this by accepting an instance URL plus a read-only personal access token, fetching the events from that instance directly, and rendering them on your public portfolio with the sensitive details (project IDs, internal hostnames, asset URLs) optionally redacted. The same widget works against gitlab.com for indie maintainers and against gitlab.example-corp.com for enterprise platform engineers.

GitLab's product strategy from day one was the single application: source control, CI/CD, container registry, package registry, security scanning, and value stream analytics in one tool. GitHub took the opposite path, building an ecosystem (Actions, Codespaces, Dependabot, Advanced Security, Copilot) of independent products that customers stitch together. Both approaches work, and the choice often reflects buying preference more than feature gaps. Where it matters for a widget: GitLab activity is denser per event because each MR carries pipeline state, approvals, and security scan results in the same response. A single MergeRequestEvent payload from GitLab is the rough equivalent of GitHub's PullRequestEvent plus a CheckRunEvent plus a CodeScanningAlertEvent. That density makes for richer widget cards out of the box (pipeline status next to MR title, security findings count next to merge state) and explains why DevOps engineers find a GitLab activity feed more informative on a portfolio than the GitHub equivalent.

GitLab also has a contribution calendar, fetched from /users/:username/calendar.json, that mirrors GitHub's signature green-square graph. Contributions are counted from pushed commits, opened MRs, opened issues, comments, and approvals. While less culturally famous than the GitHub graph, the GitLab calendar carries an additional signal that GitHub does not: pipeline contributions. Every approved CI/CD configuration change, every passing pipeline, every successful deployment shows up. For SREs and release engineers whose work is invisible on GitHub, the GitLab calendar is the only place that captures their actual day. Embedding it on a personal site (alongside a pipeline timeline and a merged MR list) is the highest-leverage proof-of-work asset for DevOps roles. The data refreshes nightly on gitlab.com and on the same schedule on self-managed instances, and Poper recolors it to your brand palette so the visualization fits your portfolio rather than feeling tacked on.

Senior platform engineers and engineering managers will Lighthouse your DevOps portfolio. They will. It is half curiosity and half a screening signal for someone who claims to care about reliability. A portfolio with a 95+ Lighthouse score reads as someone who actually ships fast pages, while a 60-score portfolio with a janky GitLab embed reads as someone who skipped the perf budget. Widgets are notorious Lighthouse killers: synchronous JavaScript blocking the main thread, layout shift from images that load late, blocking network requests on every visit. The Poper GitLab Activity Widget is engineered for this audience: async loading below the fold, scoped CSS that cannot leak into your design system, edge-cached responses so visitors never hit your GitLab instance directly, dimensions reserved on every element to keep CLS at zero, and the entire bundle gzipped under 40KB. Embed it on a Next.js, Astro, or Hugo portfolio and your Lighthouse score will not move. That matters more for a DevOps portfolio than for any other vertical because your audience is the one running the audit and rejecting candidates whose own site does not pass.