Your own certificate

The Controller always serves the web UI and API over HTTPS on port 8080. Until you give it a certificate, it generates a self-signed one in its data directory and renews it itself, so browsers warn.

Your own certificate

Mount a certificate and key into the Controller’s container and pass them with -tls-cert and -tls-key. In compose.yml:

services:
  controller:
    command:
      [
        '-public-name',
        'controller',
        '-public-name',
        '${SHARDKEEP_PUBLIC_NAME}',
        '-local-node',
        'local',
        '-local-node-token-file',
        '/var/lib/shardkeep-local/enroll-token',
        '-tls-cert',
        '/etc/shardkeep/tls/fullchain.pem',
        '-tls-key',
        '/etc/shardkeep/tls/privkey.pem',
      ]
    volumes:
      - /etc/letsencrypt/live/shardkeep.example.com:/etc/shardkeep/tls:ro

Restart the Controller after renewing the certificate. With your own certificate, the Controller also sends HSTS.

This certificate is for browsers and API clients only. Agents connect on ports 8443 and 8444 with certificates from the Controller’s own certificate authority, and nothing changes for them.

Behind a reverse proxy

A reverse proxy in front of port 8080 works if it connects to the Controller over HTTPS. Two things to know:

• Agents must reach ports 8443 and 8444 directly, or through plain TCP forwarding. They use mutual TLS, which an HTTP proxy would break.
• Shardkeep limits sign-in attempts per client address. Behind a proxy, every client shares the proxy’s address.