TLS and Certificates

All traffic to your containers is encrypted with TLS. For the common cases you never touch a certificate — Bahriya provisions and renews them for you. For the cases where you supply your own certificate material, the vault holds it. This article covers both.

Updated 3 Aug 20263 min read

Automatic TLS on default hostnames

Every HTTP container is reachable at a default hostname of the form:

https://<handle>.<region>.x.on.bahriya.app

Bahriya automatically provisions and renews a TLS certificate for this hostname the moment the container goes live. There is nothing to configure and nothing to renew — the certificate is issued, kept valid, and rotated for you throughout the life of the container.

The same automatic handling applies to vanity hostnames used for multi-region routing.

Automatic TLS on custom domains

When you point your own domain at a container, Bahriya provisions a certificate for that domain too, once the DNS records are in place. This typically completes within a few minutes of DNS propagating.

You do not upload a certificate or manage renewals for a custom domain — the platform handles issuance and rotation for the lifetime of the domain attachment. See Setting up a custom domain for the full walkthrough, including the DNS records each routing mode needs.

Tip

If a custom domain shows a certificate warning shortly after setup, DNS has usually not finished propagating. Give it a few minutes and confirm the record points at the target shown in the console.

Bringing your own certificate

Some workloads need certificate material you manage yourself rather than a platform-issued certificate on the ingress — for example:

A container that terminates HTTPS itself and needs its own server certificate and key.
Mutual TLS (mTLS) between your services.
A managed datastore or cache that requires a TLS connection using a CA you supply.

For these, store the material in a TLS bundle. A bundle holds the three pieces your workloads need: a CA certificate, a server certificate, and a private key.

When you attach a bundle to a container you choose a mount path, and the three files appear there:

<mount-path>/ca.crt     # CA certificate
<mount-path>/tls.crt    # Server certificate
<mount-path>/tls.key    # Private key

Your application reads them from that path.

How the material is protected

The private key is never displayed in the console, API responses, or CLI output. It is stored encrypted at rest and only decrypted when rendering the deployment for your containers.
Bundles are versioned. Rotation creates a new version and retains the previous one for rollback. File-mounted containers pick up rotated certificates automatically within about a minute; if you need an immediate restart, redeploy from the container's consumers panel.
The console shows each bundle's subject, issuer, fingerprint, algorithm, and expiry, so you can spot an expiring certificate at a glance.

Which approach to use

Situation	Approach
Public HTTP container on a default or custom domain	Automatic TLS — nothing to do
Your application terminates HTTPS itself	TLS bundle mounted into the container
mTLS between services, or a datastore needing your CA	TLS bundle