Guides

Custom domains

Every app is reachable over HTTPS the moment it goes live. Attaching your own hostname is one call — with one important limitation to know about first.

The hostname you get for free

Codara assigns every app a managed hostname at creation and starts provisioning its certificate. You do not have to configure DNS; the app page reports when routing and TLS are ready.

https://<managed-label>-<workspace>.codara.cloud

When an environment contains a single service, the URL uses the project name instead of the app name, which reads better for the common one-service case. Apps created before mid-2026 may still be on the older *.apps.codarasolutions.com scheme and can be migrated to the current one from the app’s domain settings.

The exact hostname is always shown on the app page, or:

bash

$ codaracloud domains list my-api$ codaracloud open my-api

Renaming a workspace breaks its generated URLs immediately

The workspace address is part of every generated hostname. Renaming it rewrites those hostnames and the old URLs stop working at once, with no redirect. Treat a workspace address as permanent once anything real points at it.

Registering a domain for your organization

If you will use one domain for several apps, register it once under Settings → Domains. Codara returns a single TXT record for the domain (for example _codara-verify.acme.com). Once that record is found, every hostname at or beneath the domain — such as api.acme.com or staging.eu.acme.com — can be attached to any app in the organization without a per-hostname challenge. Only owners and admins can register or remove domains; every member can see them. A verified domain is re-checked in the background about once a day, so a domain that changes hands stops being trusted.

The included codara.cloud hostnames need no registration at all: each app gets one automatically.

Attaching your own domain

External domains require two DNS steps

For a hostname outside codara.cloud, first publish the TXT ownership challenge returned by Codara. After the hostname is accepted, point a CNAME at customers.codara.cloud. The operator then creates a dedicated Ingress and cert-manager requests its TLS certificate.

Add the hostname

bash

$ codaracloud domains add my-api app.acme.com

Or use the Domains tab on the app page in the console.

Prove you own the domain

For a customer-owned domain, Codara returns a TXT record to publish before the hostname is accepted:

_codara-verify.app.acme.com.   TXT   "<token Codara gives you>"

Publish it with your DNS provider, then run the command again. Generated codara.cloud hostnames do not use this flow.

Point DNS at Codara

Create a CNAME:

app.acme.com.   CNAME   customers.codara.cloud.

At an apex domain (acme.com with no subdomain), use whatever flattened-alias record your provider offers — ALIAS, ANAME, or CNAME flattening. Codara accepts either form.

Wait for the certificate

Certificate issuance normally takes a couple of minutes once DNS resolves. The hostname will not become ready until its CNAME or flattened alias reaches Codara.

Checking status

The console’s Domains tab reports live DNS and certificate state per hostname, which is what you want while waiting for a domain to come up.

The CLI does not show domain status

codaracloud domains list shows the hostnames attached to an app but not their DNS or TLS state. Use the console to diagnose a domain that is not working. A status of unknown there usually means a slow DNS lookup rather than a real failure — check again shortly.

Rules

A hostname can only be attached to one app. Attaching one that is already in use fails and tells you which app currently owns it.
Managed hostnames must be exactly one label below codara.cloud — api-acme.codara.cloud is valid, v2.api-acme.codara.cloud is not.
Some names are permanently reserved and cannot be claimed.
A hostname inside another customer’s zone can never be claimed.

Removing a domain

bash

$ codaracloud domains remove my-api app.acme.com

Codara only removes DNS records it created itself. A record you added at your own provider stays until you delete it.

Ports

Traffic is sent to port 8080 by default, and the chosen port is injected into the container as PORT. To change it:

bash

$ codaracloud apps update my-api --port 3000 --client my-workspace

Changing the port restarts the app. Reading PORT from the environment rather than hardcoding a value avoids the issue entirely.

Sleep and wake

Apps can scale to zero when idle and wake again on the next request to their codara.cloud address. This is off by default — enable it per app.

bash

# Sleep after 30 minutes without a request, wake on HTTP$ codaracloud apps autosleep my-api --enabled --idle-after 1800 --wake-on-http # Turn it off$ codaracloud apps autosleep my-api --disabled # Sleep or wake right now$ codaracloud apps sleep my-api$ codaracloud apps wake my-api

When a sleeping app receives a request on its codara.cloud address, Codara starts it and holds the request for a few seconds. If it comes up in time the request is served normally; if not, browsers get a self-refreshing “waking up” page and API clients get a 503. Expect a noticeable delay on the first request after a sleep.

Three things that will not wake an app

Requests to a custom domain. Wake-on-request only works on the app’s codara.cloud address. Custom domains route straight to the app, so a sleeping app on a custom domain stays down. Keep a service with a custom domain on Always on.
Internal traffic. App-to-app calls bypass the waking layer, so a private dependency must stay awake.
A paused or suspended app. Its environment is paused, or Codara has suspended it (for example over a spend cap).

Only idle-based sleeping is active

The autosleep setting accepts scheduled and manual-only modes, but only idle is honoured today. An app set to another mode simply never sleeps automatically — manual sleep and wake still work.

Private service-to-service traffic

Apps in the same environment reach each other over the internal network using CODARA_PRIVATE_URL, without going through the public internet or consuming a domain. Traffic between different environments, projects or workspaces is blocked. See Core concepts.

Last updated 26 September 2026