Custom Domains

Contact your Skuid representative to access this feature.

Custom domains can make your Skuid sites accessible at any domain you own.

  • Without a custom domain:
  • With a custom domain:

This can be particularly useful for your site’s branding and discoverability, allowing you to make your Skuid site available alongside sites within your portfolio of domains.


Familiarity with DNS concepts

You’ll need to be able to access and update the DNS settings of your DNS provider. This process involves creating a canonical name (CNAME) record that points to the proper Skuid site and a text (TXT) record for certificate renewal.

When setting up a custom domain for Skuid, you are essentially aliasing a domain you own to point to the Skuid web address instead. When a user arrives at the domain you own, the DNS system actually redirects them to the Skuid site you’ve configured—all while retaining that same domain name.

If managing DNS is new to you, consider implementing this feature in collaboration with your IT administrator.

Purchasing a domain

Skuid does not offer domain registrar services, so you’ll need to purchase your domain from a third-party provider. As long as you can edit the DNS records for your domain—which could be done through your registrar or a different DNS management system—you can use your domain for your Skuid site.

Supported domain/record considerations

There are some considerations when configuring a custom domain for your Skuid site:

  • Only one custom domain is supported per Skuid site.

  • Skuid NLX sites are always available at their original URL.

  • Address (A) DNS records are not supported.

  • Sub-paths are not supported as custom domains. Only complete sub-domains with no paths may be used:

    • Supported:
    • Unsupported:

    Because of this, aim for a general purpose subdomain that encompasses all apps in your Skuid site instead of a subdomain specific to a single app:

    • General purpose subdomain (Recommended): or
    • App-specific subdomain (Not recommended):

On root domains

Root domains, also known as apex domains, are when a user navigates to a URL that does not include a protocol or subdomain. For example, in the URL, the root domain is

CNAME records used for custom domains cannot be mapped to a root domain; a subdomain must always be provided.

It may be possible to forward traffic from your root domain to the Skuid site-assigned subdomain, but this functionality (and how to accomplish it) varies between DNS providers. Consult your provider’s documentation.

Configuring a custom domain

To configure a custom domain:

  1. Navigate to Settings > Site Branding.
  2. In the Custom domain pane, click Add.
  3. Enter the subdomain and domain base.
    • Subdomain is required.
    • Domain base should contain your second-level domain and your top-level domain.
  4. Click Next. Skuid begins generating the information needed for your DNS records.
    • If Skuid appears to be taking too long to generate these values, it may not be able to confirm that the URL is a valid domain. Click Back and ensure that there are no errors in either the subdomain or domain base fields—such as extra periods in the subdomain.

With the DNS values generated, the Skuid site’s custom domain enters a pending state, during which Skuid checks for necessary DNS records.

In your DNS manager, create new TXT and CNAME records with values as indicated in the Skuid UI. The exact method to do this varies between DNS managers. Consult your DNS manager’s documentation for exact steps.


When creating these records, be sure that the values match. Some DNS providers automatically append portions of your domain when entering records, so it can be easy to create “double appended,” malformed records:

  • Correct:
  • Incorrect:

Some common domain registrar and DNS management services include:


If you have any existing records at a root domain or subdomain, editing these DNS records can override existing pages that users see at that address. If your domain hosts material in addition to your Skuid site, this could have impacts on your end users.

After updating your DNS records, Skuid can verify they exist and are correct. Skuid attempts to verify each time you visit this page, and you can also trigger verification manually by clicking Check.

Once the DNS records have been verified, click Activate. Users cannot access a Skuid site through a custom domain until it is activated; they will see 401 Unauthorized Invalid cookie errors when a custom domain is deactivated.

How long does DNS propagation take?

DNS propagation typically occurs quickly, sometimes taking a few minutes up to a couple of hours. However, it can sometimes take up to 24-48 hours for changes to propagate fully across the internet. This is due to several factors, including the time-to-live (TTL) value set for any existing DNS records. This TTL value determines how long DNS servers will cache the records before refreshing them.

If DNS propagation seems to be taking too long, consider the following:

  • If you’re fairly certain the TTL has expired, but you’re still seeing the old content at the web address, ensure your browser’s local cache has been cleared.
  • Some browsers have unique DNS considerations. Try visiting your custom domain from multiple browsers. If it works in one and not another, then DNS propagation was likely successful, and the problematic browser may just need more time for its cache to clear.
  • If users need to access your Skuid site in the meantime, your skuidsite domain always works, even with a custom domain configured.

Removing or updating your custom domain

Changing a domain could cause downtime for your end users. While your skuidsite domain always serves your site, users may not be familiar with that URL. Once a domain is set, try to only change your settings when transferring to a new domain or if you are encountering issues configuring your current custom domain. Always try to plan these changes during a predetermined and communicated maintenance window during non-peak hours.

To remove your custom domain:

  1. Navigate to Settings > Custom Domain.
  2. Click Remove.
  3. In the confirmation modal, click Remove.
  4. Next, navigate to your DNS management and remove the CNAME record pointing to your Skuid site.

Your Skuid site will remain available at the previous custom domain for some time—usually around an hour. This is because the domain’s DNS record that navigates visitors to your Skuid site typically has a TTL period of 3600 seconds, though this can vary depending on your configuration.

After that TTL expires, browsers will no longer navigate to your Skuid site from the previous custom domain. Your Skuid site will then only be available at its default URL until another custom domain is configured.

To update a site to use a new custom domain, remove the existing domain and configure the new domain through the same activation process as above.

App and page URLs with a custom domain

When a custom domain is set, all Skuid app paths are appended to it automatically; end users do not necessarily know they are navigating a Skuid site.

For example, consider a Skuid site at the address It has a marketing app available at

After setting its custom domain to, users could expect the following behaviors:

  • Visiting would redirect users to their default app
  • The marketing app would be available at

Updating callback URLs and allowlists

Two notable areas impacted by custom domain use are callback URLs for data sources, URL allowlists for features like Iframes, and cross-origin resource sharing (CORS) rules. You must update these settings in any relevant external systems for Skuid to continue functioning as expected.

  • To add an additional callback URL: In OAuth configuration, add an additional callback URL in this format: https://<custom domain>/auth/oauth/callback.

    For example, with a custom domain of the new callback URL would be:


    You typically do not need to remove an existing callback URL to add a new one. If you must delete the existing URL, only do so if end users only access your Skuid site at the custom domain.

  • To update allowlists and CORS rules: Add the new domain wherever required by your system. You typically need just the domain without any addition paths, e.g.