Here's my configuration that's worked reasonably well in different organizations and project sizes:

To build:

1. The applications are located in a git repository (GitLab in your case). Each application brings its own Dockerfile.
2. I use Jenkins for building, you can, of course, use any other CD tooling. Jenkins pulls the application's repository, builds the docker image and publishes it into a private Docker repository (Nexus, in my case).

To deploy:

1. I have one central, application-independent repository that has a docker-compose file (or possibly multiple files that extend one central file for different environments). This file contains all service definitions and references the docker images in my Nexus repo.
2. If I am using secrets, I store them in a HashiCorp Vault instance. Jenkins pulls them, and writes them into an .env file. The docker-compose file can reference the individual environment variables.
3. Jenkins pulls the docker-compose repo and, in my case via scp, uploads the docker-compose file(s) and the .env file to my server(s).
4. It then triggers a docker-compose up (for smaller applications) or re-deploys a docker stack into a swarm (for larger applications).
5. Jenkins removes everything from the target server(s).

If you like it, you can do step 3. via Docker Machine. I feel, however, its benefits don't warrant use in my cases.

One thing I can recommend, as I've done it in production several times is to deploy Docker Swarm with TLS Encrypted endpoints. This link talks about how to secure the swarm via certificate. It's a bit of work, but what it will allow you to do is define services for your applications.

The services, once online can have multiple replicas and whenever you update a service (IE deploy a new image) the swarm will take care of making sure one is online at all times.

docker service update <service name> --image <new image name>

Some VPS servers actually have Kubernetes as a service (Like Digital Ocean) If they do, it's more preferable. Gitlab actually has an autodevops feature and can remotely manage your Kubernetes cluster, but you could also manually deploy with kubectl.