.svg?fit=max&auto=format&n=mBaWmVpTOpDBIB6_&q=85&s=36c7989ebe591de9ac7d3618f0a04a28)
.svg?fit=max&auto=format&n=mBaWmVpTOpDBIB6_&q=85&s=5afe473ba3ef2469d3e839045bcb099c)
Connecting a domain
Add your domain on the app’s Settings > Domains page. Meridian gives you three DNS records to create at your DNS provider:
A bare domain such as
example.com can’t carry a CNAME at most DNS providers, so for one of those Meridian shows an A record with Meridian’s address instead of the CNAME that points the domain at Meridian.
The ownership token is new every time you add the domain, so a TXT record left from an earlier connection doesn’t count: replace its value with the one on the screen. Meridian checks the record once. After the domain is connected you can remove it, and the domain stays live. Domains connected before the ownership record existed don’t need one.
The domain then moves through three states:
- Pending DNS: Meridian is waiting for the
_acme-challengerecord to resolve, or for the ownership record. - Issuing certificate: the record resolved, and Google is issuing the certificate, usually within minutes.
- Active: the certificate is issued, ownership is proven, and your app is reachable on the domain over HTTPS.
the-meridian.ai, the-meridian.app and every name under them, can’t be added as custom domains, and neither can a domain another app on Meridian already holds.
Meridian checks every few minutes, and Re-verify checks straight away. Each record shows a check mark once public DNS returns it. Meridian keeps the certificate renewed through the same _acme-challenge record, so leave it in place.
Moving a domain without downtime
The certificate depends only on the_acme-challenge record, not on where the domain points. To move a domain that is live somewhere else, add the TXT and _acme-challenge records first and wait for Active, then change the domain’s own record to Meridian. HTTPS works from the first request that reaches Meridian.
Cloudflare and other proxies
A proxy such as Cloudflare in front of the domain works. The certificate is issued through the_acme-challenge record, which the proxy doesn’t touch. Point the proxied record at edge.the-meridian.app. The screen may then show the record that points the domain at Meridian as not detected, because public DNS returns the proxy’s addresses, which is expected. Use Cloudflare’s Full (strict) SSL mode so the proxy talks to Meridian over HTTPS.
If the certificate fails
If Google can’t issue the certificate, usually because the_acme-challenge record was missing or wrong for too long, the domain shows failed with Google’s reason. Fix the record, then select Re-verify to start issuance again.
With the CDN add-on, your custom domains are cached like the default domain.
Form actions work on the custom domain without any change to your app. The edge router accepts a POST from whichever of your hostnames served the page and still refuses one from anywhere else. See React Router apps: form actions through the edge router.
Removing a domain
Removing a custom domain stops serving your app on it and frees the hostname, so you can add it back later. If Meridian can’t release the domain on its side, the domain stays in the list as failed: remove it again to retry.External domains
An external domain is thehttps:// origin of your app when it runs outside Meridian, on Heroku, Fly or your own server. Meridian does not serve it, so there is no DNS record to add and no certificate to provision. It tells Meridian where to forward your Shopify webhooks.
Add one on the app’s Settings > Domains page, under External domains. Unlike custom domains, they don’t depend on your plan, so every app can add them, up to 10 per app. The origin is https:// with no path, and a hostname can’t be both a custom domain and an external domain of the same app.
A new external domain is pending until you click Verify in its detail panel. Meridian then sends a signed challenge to /webhooks/shopify on that origin, and your app answers it with the SDK. See The host verification challenge. The domain becomes verified, or failed with a short reason such as HTTP 401, which usually means the app holds a different signing secret. Verified means your app answers at that origin and holds the signing secret. It does not prove you own the domain.
To receive forwarded webhooks there, select the domain as the forward host on the Pub/Sub > Webhooks page. If a later verification of the selected domain fails, it stays selected but forwards fall back until it passes again: to your Meridian deployment when there is one, otherwise they don’t reach your app.
Removing the external domain that is your forward host asks for confirmation first, and says where forwards go once it is gone: your Meridian deployment when the app is deployed, otherwise nowhere your app can see. Removing any other external domain changes nothing about delivery.