GitLab integration

The problem

GitLab stays the source of truth for code and CI, while Kubernetes is where images must land. Between them often sits a fragile chain of webhooks and custom glue.

Teams need predictable linkage-who may deploy from which project and how that is proven in an audit.

Risks of ad‑hoc glue

Drifting image tags, unclear registry permissions, manual tag typing during rollout.

Hard to explain a single story to security or stakeholders when half the steps live in private script repos.

What Opsy adds

A managed layer on Kubernetes that respects the GitLab loop-projects, images, and deploy paths stay aligned across tools.

Fewer surprises when people rotate: less cron magic, more transparent steps.

Docs and API

HTTP API, examples, and integration depth are on the API & integrations topic page.

Typical “code → image → cluster” loop

In a mature setup GitLab ensures a vetted image lands in the registry with a clear tag or digest. The next layer decides which cluster and parameters apply.

If that layer is webhooks without a unified access model, the wrong token or project often triggers deploys.

Compliance needs a chain: which MR, which pipeline, which image, and which Kubernetes action matches.

When integration matters most

• Multiple product teams share GitLab groups and clusters.
• Images are built once but promoted to environments with different policies.
• You must align dev, platform, and security on who can ship what.
• Microservice count will grow without linear growth of ad‑hoc glue.

Screenshots below come from the related Opsy product topic. Click an image to open it full screen.

Product topic →   All scenarios   Open demo