Domain names

When creating an application, you have two (non-exclusive) choices for domain names:

• Using a personal domain name
• Using a cleverapps.io free domain for development and testing purposes, with built-in SSL

Add it in the application configuration: in the console, click application name in the first panel, then choose domain names. You’ll have to choose to add a custom domain name or use a subdomain under *.cleverapps.io.

Testing with cleverapps.io Domain

In the console, in the domain name sub menu of your application, there is a default entry configured by default for every new app: yourAppID.cleverapps.io, which can be removed.

In your application’s domain section, just enter example.cleverapps.io. You have to choose a unique one. Trusted SSL is available on every subdomain.

Configuring Domain Names by Region

It’s possible to point your personalized domain name to Clever Cloud with either a type A or CNAME record through your registrar.

With a CNAME record, your DNS configuration is always up-to-date. Using A records requires you to keep the DNS configuration up-to-date manually.

We also support wildcard personal domain names, to do so use the standard pattern to describe it: *.example.com

Europe/Paris (PAR)

Provide the following to your registrar:

Europe/Paris onto Scaleway (SCW)

Europe/Roubaix (RBX)

Europe/Roubaix HDS (RBXHDS)

Europe/Warsaw (WSW)

Europe/Gravelines (GRAHDS)

North-America/Montreal (MTL)

Provide the following to your registrar:

Asia/Singapore (SGP)

Oceania/Sydney (SYD)

If you want to make your application available from a domain name which doesn’t support CNAME records (eg example.com in addition to www.example.com), check if your registrar provides a web redirection service. This way, you only have to make www.example.com point to Clever Cloud. Please note that web redirection provided by registrars only work over HTTP.

Remember that DNS changes may take time to propagate (usually a few hours, sometimes up to a day or more). It depends on the TTL setting of your DNS configuration. For faster changes, you can lower the TTL value in advance, and rise it again afterwards.

Contextual Example

Path routing

Requests are routed to applications based on the domain name, but you can also route depending on its path.

For instance, you can bind example.com to an app, and example.com/api to another one. All the HTTP requests on example.com where the path starts with /api are routed to the second app. The other requests are routed to the first app. You can add a path after every domain name you bind in the console (or with clever tools).

Note that your path-routed application needs to have a /whatever route.

This will work:

example.com        ->      myfirtapp-main-route

example.com/api    ->      mysecond-app-main-route/api

This will NOT work:

example.com        ->      myfirtapp-main-route     (works)

example.com/api    ->      mysecondapp-main-route   (404 response from mysecondapp)

Path routing for static sites

In the case of static files, you usually understand routes as paths in a file tree.

This will work:

example.com/api    ->     my-static-site/api/index.php

This will NOT work:

example.com/api    ->     my-static-site/index.php

Gandi CNAME configuration

Here is an article that demonstrates a simple setup for Gandi CNAMEs.