Appearance
Domains & SSL
Your automatic Infrly URL
Every Web Service and Static Site gets a public URL on Infrly's own domain the moment it first deploys successfully — something like https://your-service-name-ab12cd.infrlyapp.com. You don't configure DNS or a certificate for this yourself; it's provisioned automatically as part of the deploy pipeline (the CONFIGURING_DOMAIN / CONFIGURING_SSL phases you'll see in a deployment's log), and HTTPS is on by default with no extra step.
This URL is stable for the life of the service — it doesn't change across redeploys, only if the service itself is deleted and recreated.
Custom domains
Web Services and Static Sites can also serve traffic on a domain you already own, alongside (not instead of) the automatic *.infrlyapp.com URL — both keep working.
- Open the service's Domains tab and add your domain (e.g.
app.yourcompany.com). - Add a CNAME record for it at your DNS provider, pointing at the target shown — your service's own
*.infrlyapp.comaddress. - Click Verify. Once DNS resolves correctly, Infrly automatically requests and installs a real TLS certificate for it — no separate step.
DNS propagation is the most common reason a first Verify doesn't succeed immediately; wait a few minutes and try again rather than assuming something's wrong. Certificate issuance itself is usually well under a minute once DNS is confirmed.
Apex/root domains
A CNAME technically can't live at a bare root domain (yourcompany.com, no subdomain) per the DNS spec itself — this isn't an Infrly limitation. Most DNS providers offer an "ALIAS" or "ANAME" record type that behaves like a CNAME at the root if you need this; check whether yours does.
One custom domain per service for now — remove the existing one before adding a different one.
Private (internal) addressing
Services in the same project can reach each other over Infrly's private network without going through the public internet or a public URL at all — see Environment Variables & Service References for how to use a sibling service's internal address (${{name.HOST}}, ${{name.URL}}, ...) instead of its public one. This is both faster and never exposed publicly, and is the right choice whenever two services only need to talk to each other, not to the outside world.