The GitLab PM responsible for the agent for Kubernetes work here.

The agent supports automatic (and short lived) support for registry keys for the push-based approach with [Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/stages.html#aut...), and we have documented how one can [set up container registry keys for the pull-based approach](https://docs.gitlab.com/ee/user/clusters/agent/gitops/secret...)

The difference between Argo/Flux and the agent is that Argo and Flux are pull-based deployment point solutions (especially Flux), while the agent (originally built on shared codebase with Argo) is the basic integration layer for GitLab - Kubernetes connections. This way, already today, GitLab provides integrated container vulnerability scanning that is out of scope for the other tools.

About the half-stitched solution, among the three mentioned tools, only the agent supports server-side applies. The others have it as planned features. If you ever struggled with setting up the right annotations to use pull-based deployments and any competing controller at the same time, using server-side applies provides a lot of benefits.

I use Flux, it's great once you grok it and get it configured. Docs are a bit sparse in some areas for things like containers but otherwise quite easy and powerful to set up. One example is that I had my infra code stored in Github and wanted to migrate it to Gitlab. Simple as pushing the existing repository up to Gitlab instead and then flux init Gitlab - everything works as it did before.

> They forgot one con off pull based deployments which is that you need to put a repository key in your cluster where your code is running.

Conversely for push-based deployments, there's a process running somewhere outside your cluster that has admin access to your cluster. Did you analyze the threat models for both push and pull, and decide that push is less risky?