Dibbla Docs Get started Guides Workflows Changelog
Open Console
Guides

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:

  1. Connect the hostname to the app — in the console, from the CLI, or through your code assistant.
  2. Add one DNS record at whoever hosts your domain’s DNS: a CNAME from the hostname to cname.dibbla.com.
  3. 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.
Use www, not the bare domain

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.

Say this to your code agent

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:

FieldValue
TypeCNAME
Host / Namewww (the part before your domain)
Target / Points tocname.dibbla.com
TTLleave 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:

  1. 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).

  2. Add the CNAME

    Add a record: Type CNAME, Hostname www, Points to cname.dibbla.com, TTL default. Remove any existing A or CNAME record for www first.

  3. 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.

  1. Open the DNS editor

    Log in to Loopia Customer Zone, open Domains → your domain → DNS editor.

  2. Select www

    Select the subdomain www — add it with Add subdomain if it is not listed. Remove any existing A record on it.

  3. 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.

  1. Open DNS records

    In the Cloudflare dashboard open your zone → DNS → Records.

  2. 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.

  3. 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.

  1. Open DNS

    Log in to GoDaddy, open My Products → your domain → DNS.

  2. Add the CNAME

    Add a new record: Type CNAME, Name www, Value cname.dibbla.com, TTL default. Delete any existing www record first.

  3. 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).

  1. Open Advanced DNS

    Log in to Namecheap, open Domain List → your domain → Manage → Advanced DNS.

  2. 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.

  3. 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.

  1. Open DNS settings

    Log in to Squarespace Domains (domains from Google Domains moved here), open your domain → DNS → DNS settings.

  2. Add the CNAME

    Under Custom records, add: Host www, Type CNAME, Data cname.dibbla.com, TTL default.

  3. 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.

  1. Find DNS management

    Open the DNS management page for your domain at whoever hosts its DNS — usually the registrar you bought it from.

  2. Add the CNAME

    Add a CNAME record 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.

  3. 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.com directly at cname.dibbla.com. Connect the bare domain like any other hostname.
  • Everyone else — One.com, Loopia, GoDaddy, Squarespace and most registrars — cannot. Connect www.example.com to the app and set up web forwarding at the registrar from example.com to https://www.example.com. Visitors who type the bare domain land on www, 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

StatusWhat it meansWhat 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 list and verify show status disconnected; the platform connector’s view=domains says the same.
  • Connect again — or dibbla domains add with 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 CNAME is 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 in dibbla.yaml sets the ingress hostname on your own install; DNS and certificates are then your ingress and issuer’s job. See the manifest reference.