Jasper -
I think you want to establish some form of communication between GitLab and your server, in particular, GitLab should be able to initiate events on the server in response to events (changes) in the GitLab repository.
A common pattern for a solution is to use a webhook -- a feature of GitLab (I assume, I use GitHub) that allows you to instruct GitLab to perform a given action when something happens in GitLab. You can choose which things, for example, you might choose to have GitLab fire the webhook whenever there's a push.
What happens when the push occurs? You need to pull from the repo, build a new container, upload it to the container repo, then run docker using the new container.
The webhook is expected to be a URI that refers to a remote server ... in particular, the remove server needs to be listening on the port specified by the URI. The most common port is either the HTTP port 80, or the HTTPS port 443 -- and the reason they are popular is that many systems don't block them, as they do with most other ports. So you need something on your server listening on port 80/443 that will do these steps.
So the steps needed (pull, build, upload, run) often fall into two phases: "build" and "run", where build includes all the steps needed to deploy a workable application. GitHub offers "github actions" -- I suspect GitLab has something similar -- that give you access to a temporary compute resource for things like running commands e.g. "pull", "compile", and "docker". Or, you could build a basic web server app that ran these commands. Either way, something on the server will need to run docker (or maybe ask it to restart) using the newly built image.
Could you use Kubernetes for this ... sure ... but as you imply, it's too much for the single task. Learning how to deploy kubernetes is a lot of work. Instead, Google "xyx web server" where xyz is the programing language or environment to find a suitable installable server. Most offer a simple way to integrate system commands and respond to webhooks.