Custom domains
Serve your app on a domain you own — connect the hostname, add one CNAME record at your DNS provider, and the certificate is issued automatically. Step-by-step for One.com, Loopia, Cloudflare, GoDaddy, Namecheap and Squarespace.
Every app is served at its platform address from the first deploy, with TLS,
and that address is not going anywhere. This page is about serving the same
app on a hostname you own — www.example.com — with a certificate for that
name, issued and renewed for you.
It is three steps, and only one of them happens outside Dibbla:
- Connect the hostname to the app — in the console, from the CLI, or through your code assistant.
- Add one DNS record at whoever hosts your domain’s DNS: a
CNAMEfrom the hostname tocname.dibbla.com. - Wait a few minutes. Once the record resolves, the certificate is issued at the edge and the domain goes Active. Nothing to upload, nothing to renew.
Connect www.example.com, not example.com. Most DNS providers cannot put a
CNAME on the bare domain, and the fix there is a redirect from
example.com to www.example.com — see The bare domain
below. Cloudflare and Namecheap are the exceptions and can point the bare
domain straight at the platform.
Connect the hostname
Open the app in the console and pick the Domains tab. Type the hostname and press Connect domain. The domain appears with a Waiting for DNS badge and, right under it, the record to add — type, host and target, each with a copy button — plus a guide for your DNS provider with your own hostname filled in.
The badge updates by itself, every ten seconds, until it turns Active · SSL ready (green) or Configuration error (red). You do not need to reload.
Disconnect on the same row stops the app answering on the domain. The row stays, grey, with Connect again — see Disconnecting a domain below.
$dibbla domains add my-app www.example.com ✅ www.example.com is connected to 'my-app'. Create this DNS record at your registrar: Type: CNAME Host: www Target: cname.dibbla.com Status: waiting for DNS — create the CNAME www.example.com → cname.dibbla.com, then run verify again
$dibbla domains verify my-app www.example.com ✅ www.example.com: active — serving with a valid certificate https://www.example.com
$dibbla domains list my-app $dibbla domains remove my-app www.example.com
verify reads the current status from the edge every time you run it, so
it is the command to repeat while you wait. --json on add, list and
verify prints the raw document for scripts.
On the platform connector, domains are part
of the app tools: platform_apps with view=domains lists them (narrow
to one with hostname=), and platform_app_config_update with
domain_add or domain_remove connects or disconnects one. The answer
carries the same CNAME instruction and status verdict as the CLI.
Have the assistant connect the domain and tell you the record to add.
Connect www.example.com to my app my-app on Dibbla, then tell me exactly which DNS record to create at my registrar (type, host and target) and how to check when it has gone active. Add the DNS record
Whichever way you connected the hostname, the record is the same:
| Field | Value |
|---|---|
| Type | CNAME |
| Host / Name | www (the part before your domain) |
| Target / Points to | cname.dibbla.com |
| TTL | leave the default |
If www already has an A, AAAA or CNAME record, delete it first — a
CNAME cannot share its name with other records. Then pick your provider:
-
Open DNS settings
Log in at one.com and open the control panel for your domain. Go to DNS settings → DNS records (on some accounts it sits under Advanced settings).
-
Add the CNAME
Add a record: Type CNAME, Hostname www, Points to cname.dibbla.com, TTL default. Remove any existing
AorCNAMErecord forwwwfirst. -
Save and wait
Save. Changes usually spread within minutes. The console badge, or
dibbla domains verify, tells you when the certificate is in place.
Bare domain: One.com cannot put a CNAME on example.com. Open
Web forwarding (under Domain or Advanced settings) and forward
example.com to https://www.example.com as a permanent (301) redirect,
keeping the path.
-
Open the DNS editor
Log in to Loopia Customer Zone, open Domains → your domain → DNS editor.
-
Select www
Select the subdomain www — add it with Add subdomain if it is not listed. Remove any existing
Arecord on it. -
Add the CNAME
Add a record: Type CNAME, TTL 3600, Data cname.dibbla.com. Save.
Bare domain: Loopia cannot put a CNAME on example.com. In Customer
Zone, open your domain’s Forwarding (Vidarebefordring) and forward
the domain to https://www.example.com.
-
Open DNS records
In the Cloudflare dashboard open your zone → DNS → Records.
-
Add the CNAME — DNS only
Add a record: Type CNAME, Name www, Target cname.dibbla.com, TTL Auto. Set Proxy status to DNS only (grey cloud). The certificate is issued at Dibbla’s edge; a proxied (orange) record would sit in front of it.
-
Save
Save. Cloudflare’s own changes are live within a minute.
Bare domain: Cloudflare flattens CNAMEs on the bare domain, so you
can connect example.com directly: Type CNAME, Name @, Target
cname.dibbla.com, DNS only.
-
Open DNS
Log in to GoDaddy, open My Products → your domain → DNS.
-
Add the CNAME
Add a new record: Type CNAME, Name www, Value cname.dibbla.com, TTL default. Delete any existing
wwwrecord first. -
Save and wait
Save; GoDaddy changes usually spread within an hour.
Bare domain: GoDaddy cannot put a CNAME on example.com. On the DNS
page open Forwarding → Domain → Add forwarding and forward
example.com to https://www.example.com, permanent (301).
-
Open Advanced DNS
Log in to Namecheap, open Domain List → your domain → Manage → Advanced DNS.
-
Add the CNAME
Add a new record: Type CNAME Record, Host www, Value cname.dibbla.com, TTL Automatic. Remove any parking or URL redirect record on
www. -
Save
Save all changes.
Bare domain: Namecheap supports an ALIAS record, so example.com
can point straight at the platform: Type ALIAS Record, Host @,
Value cname.dibbla.com. Alternatively use Redirect Domain to send
example.com to https://www.example.com.
-
Open DNS settings
Log in to Squarespace Domains (domains from Google Domains moved here), open your domain → DNS → DNS settings.
-
Add the CNAME
Under Custom records, add: Host www, Type CNAME, Data cname.dibbla.com, TTL default.
-
Save
Save. Changes usually spread within minutes.
Bare domain: Squarespace Domains cannot put a CNAME on
example.com. Open your domain → Forwarding and forward it to
https://www.example.com as a permanent redirect.
-
Find DNS management
Open the DNS management page for your domain at whoever hosts its DNS — usually the registrar you bought it from.
-
Add the CNAME
Add a
CNAMErecord with host/name www pointing at cname.dibbla.com. Leave TTL at the default. Some providers want a trailing dot on the target; most add it for you. -
Save and wait
Save. Propagation is usually minutes, occasionally up to a day.
Bare domain: if your provider offers an ALIAS or ANAME record
(or flattens CNAMEs), point example.com at cname.dibbla.com with it.
Otherwise connect www.example.com and set up web forwarding from the
bare domain to it. Amazon Route 53’s alias records only target AWS
resources, so there too the forwarding approach (or an S3 redirect bucket)
is the way for the bare domain.
The bare domain (example.com)
A CNAME says “this name is an alias for that one”, and the DNS standard does
not allow it on a name that also carries the domain’s own NS, SOA and mail
records — which the bare domain always does. So there are two kinds of
provider:
- Providers that flatten or alias — Cloudflare (CNAME flattening),
Namecheap (ALIAS), and any host offering ALIAS/ANAME — can point
example.comdirectly atcname.dibbla.com. Connect the bare domain like any other hostname. - Everyone else — One.com, Loopia, GoDaddy, Squarespace and most
registrars — cannot. Connect
www.example.comto the app and set up web forwarding at the registrar fromexample.comtohttps://www.example.com. Visitors who type the bare domain land onwww, which serves the app over HTTPS.
The console recognises a bare domain when you connect one, shows this advice,
and offers to connect the www variant with one click. The CLI prints the
same note.
What the status means
| Status | What it means | What to do |
|---|---|---|
| Waiting for DNS (yellow) | The hostname is registered; the edge has not yet seen the CNAME, or is finishing the certificate. | Add the record if you have not; otherwise wait. The console re-checks every ten seconds, dibbla domains verify on demand. |
| Active · SSL ready (green) | The CNAME resolves and the certificate is issued. | Open https://www.example.com. |
| Configuration error (red) | Verification did not complete — typically the certificate validation timed out or the hostname was moved or removed at the edge. | Check the record against the table above, then disconnect and connect the domain again. |
| Disconnected (grey) | You disconnected the domain. No app answers on it; visitors see Dibbla’s “This site isn’t connected” page while your CNAME still points here. | Connect again to put it back (instant, no new certificate), or remove the CNAME at your provider to let it go. |
A Waiting status usually lasts a few minutes after the record is saved.
DNS changes at some providers take up to an hour to be visible; a domain that
has been waiting longer than that almost always has a typo in the record or a
leftover A record on the same name.
Disconnecting a domain
Disconnecting takes the app off the hostname — nothing more. Your DNS record
is yours and is never touched, and Dibbla keeps the hostname registered at
its edge for a while, on purpose: as long as your CNAME still points at
cname.dibbla.com, a visitor who types the address must land somewhere, and
if the edge had already forgotten the hostname that somewhere would be a bare
Cloudflare error page (1014 or 530) with no explanation. Instead they see
Dibbla’s own page — This site isn’t connected. The domain points at Dibbla,
but no app is connected to it. — with a link to dibbla.com.
While disconnected:
- The console lists the domain with a grey Disconnected badge and a
Connect again button;
dibbla domains listandverifyshow statusdisconnected; the platform connector’sview=domainssays the same. - Connect again — or
dibbla domains addwith the same hostname, on the same app or another app of your organization — puts it straight back into service. The certificate is still there, so there is no waiting for DNS. - The hostname stays reserved for your organization. Nobody else can connect it.
The reservation ends when the platform sees that your CNAME no longer
points at cname.dibbla.com, or 30 days after you disconnected, whichever
comes first. Then the hostname is released at the edge and forgotten; if you
connect it after that, it goes through DNS verification like a new domain.
So when you are done with a domain, remove the CNAME at your DNS
provider — that is what lets it go. Until then visitors get the “not
connected” page, not your app.
Good to know
- The platform address keeps working. A custom domain is added, not swapped — the generated address serves the same app, which is what you want while DNS propagates and for anything that already links to it.
- Login works on your domain. Apps that use Dibbla’s login gate or SSO sign in on the custom hostname and keep their session there; nothing to reconfigure.
- One hostname, one app. A hostname can be connected to one app on the
platform at a time; connecting it elsewhere is refused until it is
disconnected — and a disconnected hostname stays reserved for its
organization until the
CNAMEis removed (or 30 days). Several hostnames on one app is fine. - HTTP and HTTPS only. Custom domains front the app’s web routes. Database and other TCP routes stay on their platform addresses.
- Self-hosting? The
domain:field indibbla.yamlsets the ingress hostname on your own install; DNS and certificates are then your ingress and issuer’s job. See the manifest reference.