Build Prod Image in CI and deploy container on multple Servers

[svenpet90]

My plan is to build the app-php-prod container in my gitlab ci, push it to the registry and then pull it on several independent servers/instances (I am running a Saas where each client gets their own server/instance with the same App/Docker image running on it).

I have more than 70 Servers by now and dont think its nessesary to build the exact same Image on each server, everytime i deploy a new version.

So I created a new compose file, pulling my build image and running it.
The Container itself runs fine, but it creates no SSL Certificate.

The certificate is:
(CN) *.vm
Organisation (O) Docker Boilerplate
Organisational unit (OU) <Gehört nicht zum Zertifikat>

Does anyone know what I am missing?
Thanks in adavance!

[yudin-s]

Building the production image once in CI is fine. The certificate part is runtime configuration, not something that gets baked correctly into the image.

In this template the php service is also the FrankenPHP/Caddy server. The Caddyfile uses:

{$SERVER_NAME:localhost} {
  ...
}

So if the container starts without a real SERVER_NAME, or with a name that Caddy cannot validate through public DNS/ports 80 and 443, you will get the local/internal certificate behavior instead of a Let's Encrypt certificate. The *.vm / Docker Boilerplate certificate is a strong sign that the runtime is still using development/local defaults somewhere.

For each customer server I would keep the same pushed image, but pass per-server runtime env/config, for example:

SERVER_NAME=customer1.example.com \
APP_SECRET=... \
CADDY_MERCURE_JWT_SECRET=... \
docker compose -f compose.yaml -f compose.prod.yaml up -d

Then check these deployment details:

1. DNS for that customer hostname points to that server.
2. Ports 80 and 443 are reachable from the internet if Caddy should obtain Let's Encrypt certs.
3. Your runtime compose file still publishes the HTTP/HTTPS ports from the FrankenPHP/Caddy service.
4. You persist Caddy data/config volumes if you do not want certificates to be reissued on every recreate.
5. You are not copying a development override that sets SERVER_NAME=localhost or SERVER_NAME=:80.

If TLS is terminated by a different reverse proxy/load balancer, then set this container to HTTP mode instead and let the outer proxy manage certificates. If the container itself should own TLS, the missing piece is usually the per-instance SERVER_NAME plus reachable DNS/ports, not rebuilding the image on each host.

If this solves it, please mark this comment as the answer so other people can find it faster.