Give public services secure addresses
A public application needs addresses that reach the right service and certificates that browsers can trust. Wildo derives public routes from the environment’s hostnames and connects the deployed edge to certificate issuance.
Choose the domain and service names, then make DNS and the deployed edge reachable. The configured edge or certificate controller handles issuance; the operator owns the environment in which it runs.
Example — Put the application and documentation on their own addresses
The application uses app.example.com, documentation uses docs.example.com and the website uses example.com. The same hostname declarations guide the ingress and the addresses given to application consumers.
For engineers
Declare the names and issuer
This fragment belongs in a remote Kubernetes environment. Provider identifiers and registry settings below are illustrative operator choices; the field shape and service-host pattern follow the production descriptor.
publicDomain: 'example.com',
serviceHosts: {
app: 'app',
docs: 'docs',
website: '',
},
remoteProvider: {
provider: 'scaleway',
registryEndpoint: 'rg.fr-par.scw.cloud/example',
acmeEmail: 'operations@example.com',
tlsIssuer: WildoTlsIssuer.LETSENCRYPT_STAGING,
},
Import WildoTlsIssuer from @wildo-ai/platform-config-lib. Validate DNS and routing with the staging issuer, then select LETSENCRYPT_PROD for browser-trusted issuance. The staging certificate is intentionally not a production trust result.
Use the TLS owner for the selected runtime
The public hostname inputs are shared; certificate ownership differs:
| Runtime | TLS owner and issuance inputs | Where certificate state lives |
|---|---|---|
| Remote Docker Compose | Traefik discovers the generated container routers, redirects HTTP to HTTPS and uses Let’s Encrypt HTTP-01 with remoteProvider.acmeEmail | /letsencrypt/acme.json in the persistent wildo-letsencrypt volume |
| Remote Kubernetes | cert-manager uses the selected ClusterIssuer and its ACME registration email; the ingress requests certificates for its routed hosts | Kubernetes TLS Secrets, referenced by the ingress |
| Local Kubernetes edge | Separate self-signed issuer and local wildcard certificate | Local cluster certificate/Secret resources; workstation trust is configured separately |
The remote Compose application generator supplies the same resolved service hosts and ACME email to its Traefik template. Preserve its certificate volume across container recreation and make the HTTP challenge reachable. The Kubernetes tlsIssuer staging/production choice shown above does not configure the Compose resolver.
Follow the generated ingress
Wildo’s Kubernetes workflows install Traefik. kubernetes.ingressClass accepts traefik or omission; other controller values are rejected in authored and saved configuration. Application ingress and HTTP-01 challenge routing use that same supported class.
The shared public-host resolver produces ingress routes and advertised runtime endpoints. It rejects hostname collisions. The application ingress template enumerates those hosts, points each at its own service and adds the configured cert-manager.io/cluster-issuer annotation.
A per-ingress TLS secret can cover the hosts enumerated on that ingress. Do not interpret this as one independently generated certificate for every hostname. Remote issuer templates use HTTP-01, while the retained wildcard alternative is not part of that rendering path.
Keep CDN frontends outside the application edge
For a frontend with enabled: true in the environment’s cdn map, Wildo preserves its advertised public URL but removes its self-hosted deployment target and public route. Kubernetes therefore emits no nginx Deployment/Service or ingress route for that frontend; remote Compose emits no corresponding application container or Traefik router. Both consume the same filtered target list.
The CDN must serve that hostname through its own publishing, origin, DNS and TLS setup. Follow the frontend CDN publishing guide for that separate path.
Distinguish the local cluster edge
The local Kubernetes bootstrap applies the separate self-signed issuer and wildcard certificate for its local domain. It does not request a public certificate through the remote HTTP-01 path. Browser trust in that local authority is a separate machine concern; a successfully applied local certificate is not evidence of remote public issuance. Ordinary host-based local development endpoints remain a different topology from the cluster edge.
Keep controller work and operator work distinct
| Wildo’s generated inputs | Environment requirements |
|---|---|
| Host-to-service routes | DNS reaches the deployed edge |
| Issuer and TLS annotations | Certificate controller and ingress controller are operating |
| Named certificate secret | Successful challenge and certificate issuance |
| WebSocket affinity annotations | Appropriate application/session behavior behind the edge |
The ingress template includes host-header pass-through and sticky-cookie routing. It does not add a general edge rate limiter or security-header policy; those belong to the application or the operator’s chosen edge configuration. Generated YAML alone does not establish successful remote issuance.