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

In addition to user-managed domains, which apply only to the Live environment, each application's environment has a fixed Divio-provided domain, for example, myapp.us.aldryn.io or myapp-stage.us.aldryn.io. The ingress controller uses this information to route requests to particular applications.

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 bare domains (e.g. example.com), we recommend using the `ALIAS records suggested in the Control Panel interface. Not all DNS providers support ALIAS records so that A records may be used. Note, however, that the IP addresses we use may change, so we recommend using ALIAS records over A records where possible.

SSL certificates​

We automatically provide free SSL certificates through Let's Encrypt for all domains using our default domain backend. Other options, such as uploading your own certificate, are available on request.

A certificate can only be applied if the domain passes automated DNS configuration tests. Once a domain is added, a check takes place. If a check fails, the domain will be checked every 15 minutes until a correct setup is detected. Once a check finds it correct, 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.