Skip to main content

Domains

Domains are managed in the Control Panel, in the Domains section of the application. They route requests to the correct application. The Control Panel allows you to set up primary and secondary domains and configure redirects between them.

Domains

Types of Domains​

Divio-Provided Domains​

Divio-Provided Domains (e.g. myapp.us.aldryn.io or myapp-stage.us.aldryn.io), are automatically assigned domains specific to each application environment. These domains are fixed and managed by the platform’s ingress controller, which uses this domain information to correctly route requests to each application environment.

Custom Domains​

Custom domains (e.g. mydomain.com), are user-provided domains that replace or supplement Divio-provided domains and are supported on live environments. These can be configured as primary or secondary, allowing users to personalize their URLs and enhance SEO.

Wildcard Domains​

Wildcard domains (e.g. *.mydomain.com), enable routing across multiple subdomains allowing multiple subdomains to be managed under a single configuration. This feature can be provided on request, with subscription requirements outlined on our pricing page.

Please refer to the Pricing Page for more details on subscription tiers that include these options.

DNS records​

The Control Panel interface shows whether DNS has been correctly configured for each domain and whether valid SSL certificates are in place.

For apex domains (e.g. example.com), we recommend using the ALIAS records suggested in the Control Panel interface. If your DNS provider does not support ALIAS records, A records may be used. However, keep in mind that the IP addresses we use may change, so we recommend using ALIAS records over A records where possible.

SSL certificates​

Default SSL Certificates​

We provide free SSL certificates for all domains by default through Let's Encrypt using our domain backend. These certificates are automatically renewed to ensure secure HTTPS connections for applications.

Custom SSL Certificates​

Customers requiring custom SSL certificates (their own including wildcard certificates) can request our support team to switch the SSL backend to Manual.

A certificate can only be applied if the domain passes automated DNS configuration tests. Once a domain is added, an initial check takes place followed by a check every 15 minutes until a correct setup is detected. After passing, subsequent checks occur every 24 hours.

Domain settings and environment variables​

In addition to providing routing to applications, domain settings also set environment variables that the applications can use internally. These environment variables are:

  • DOMAIN - the domain that is marked as Primary in the interface
  • DOMAIN_ALIASES - each of the other listed domains, except for those in:
  • DOMAIN_REDIRECTS - any domains that have the Redirect setting enabled, i.e. that should redirect to DOMAIN

Once the settings have been applied to the interface, the environment variables are also set, so there is no need to add them manually.

Deployment Required

After adding or changing environment variables, the respective environment must be redeployed to apply the configuration.

Your application may need to use these variables to function correctly. For example, a Django application has an ALLOWED_HOSTS setting, listing the hosts that the application can be served from. This needs to list all the domains applied in the interface which are made available via DOMAIN, DOMAIN_ALIASES and DOMAIN_REDIRECTS.

important

It is up to the application to read and use these environment variables correctly. For example, an application will only automatically redirect to the primary domain from another one if it can read the environment variables and apply the appropriate configuration.

(This doesn't apply to legacy Aldryn Django applications, which will configure themselves automatically using these variables. See redirects in Aldryn Django applications.)

Redirects​

Redirects in applications will typically take place at one of two different levels:

  • in the application code itself (for example, in Django or PHP)
  • in the application's web gateway or server (for example, in uWSGI or Nginx)

An application can blur the distinction between these levels, but most will include distinct code and gateway/server layers. Gateway/server-level redirects occur before a request reaches the application code (and will, therefore, be faster and less expensive). However, code-level redirects are generally easier to implement, and the overhead of handling them is minimal.

Protocol redirects​

To redirect from HTTP to HTTPS: Django, Express JS.

301 Permanent vs 302 Temporary redirects​

You will sometimes see online site-checking tools encouraging permanent redirects and even flagging temporary redirects as issues. Indeed, a permanent redirect is sometimes more appropriate, but only when it really should be permanent and is guaranteed not to change.

Protocol, domain, and language redirects are 302 Temporary by default. Browsers cache 301 Permanent redirects – some even update their bookmarks if they encounter a 301. This behaviour can cause problems if the redirects change, potentially causing redirect loops for users (which site owners cannot replicate).

Search engines​

The aldryn.io domains are publicly accessible, can be crawled by bots, and need to be protected on your end. You can do this by either adding HTTP Basic Authentication or using the language/framework you use.

This primarily concerns the test environment, which you may want to secure from public access. To prevent search engines from crawling the live site under the aldryn.io domain, you have several options:

  1. Set up a 301 redirect within your application. You can configure this on your server or consult the documentation of your technology stack.
  2. Serve different robots.txt files depending on the domain used. Set the aldryn.io domain to Disallow for crawling.
  3. Set a canonical meta tag using <link rel="canonical" href="https://your-page-url" />
  4. Provide a sitemap with the correct domain name.
  5. Use the Google Search Console or Bing Webmaster Tools to validate the correct domain.

In addition to that, make sure there are no internal links hardcoded to use the aldryn.io domain.