Custom domains with blueprints and pull request preview environments

I found these docs about custom domains: Custom Domains | Render · Cloud Hosting for Developers

and this blueprint spec seems to have a custom domain defined Blueprint Specification | Render

I was just wondering what happens when you have a custom domain defined, AND pull request preview environments defined?

Hi there,

Thanks for reaching out.

Preview Environments will ignore domains declared for the Web Service.

Hope that helps

Alan

1 Like

what if the app code itself depends on subdomain routing and normally wildcards them with wildcard DNS routing?

At least in Rails, its a first class concept Building a Rails App With Multiple Subdomains | AppSignal Blog

The default domains don’t support multi-level subdomains, e.g. foo.service-name.onrender.com. That would also require the code to know what to do with multi-level subdomains. Additionally, a wildcard custom domain can only point to one service.

I’ve not tried it personally (I’ll add it to my list of experiments to try), but maybe you could have an initialDeployHook script (docs) that utilises the Render REST API to add a custom domain with a domain structure you want, e.g. foo-preview-xxx.example.com. However, to have this completely automated, it would also need your DNS provider to have an API to be able to create the corresponding CNAME record.

Alan

yea, it’s a feature in rails, you put a subdomain constraint on a route, easy peasy. example from rails docs: Rails Routing from the Outside In — Ruby on Rails Guides

get 'photos', to: 'photos#index', constraints: { subdomain: 'admin' }

So you are saying, you can’t define subdomains in the render blueprint for pull request previews, but you’d instead have to use Render’s REST api once the service is live (but not valid yet) to then fix the DNS stuff? is it this api? Add custom domain
What if in a Pull request preview edited the blueprint with the custom domain for that pull request preview itself (that it pre registered with some DNS provider api), would that be recommended? or do you have to go the Render REST api route post-deploy?

Domain declarations in the render.yaml will only be used to update the primary service, not Preview Environments.

Any custom domain setup would need to be done after, I tested the initialDeployHook pointing at a bash script like:

SRV=$(echo $RENDER_INSTANCE_ID | cut -d '-' -f 1,2)

if [["$IS_PULL_REQUEST" == "true"]]; then
  JSON='{"name":"%s"}\n'
  DOMAIN_JSON=$(printf "$JSON" "$RENDER_SERVICE_NAME.domain.com")

  curl --request POST \
    --url https://api.render.com/v1/services/$SRV/custom-domains \
    --header "Accept: application/json" \
    --header "Authorization: Bearer $API_KEY" \
    --header "Content-Type: application/json" \
    --data "$DOMAIN_JSON"

  # hopefully this can be done with your DNS provider API
  echo "Now create $RENDER_SERVICE_NAME.domain.com CNAME record pointing at $RENDER_SERVICE_NAME.onrender.com..."
fi

And it created a custom domain on the Preview Environment.

RENDER_INSTANCE_ID, IS_PULL_REQUEST, RENDER_SERVICE_NAME are all provided by Render. You’d just need to get your API_KEY in there securely.

Alan

Do you think it would work if, instead of doing this:

 # hopefully this can be done with your DNS provider API
  echo "Now create $RENDER_SERVICE_NAME.domain.com CNAME record pointing at $RENDER_SERVICE_NAME.onrender.com..."
fi

Instead of that, we create a wildcard A record so that it can utilize subdomains (not just CNAME ones) so a url like app.ourdomain.com would work?

Another question, when I add a custom domain in the render gui, there are some warnings that pop up like this one for example:

Add a CNAME record for app pointing to internal swarm url

DNS configuration instructions

When you add a custom domain via the endpoint, does it need to pass all these checks before coming live/does it use the same checks as the GUI?

If you’re still referring to Preview Environments, then using the anycast IP as an A-record on the wildcard would allow custom domains to resolve, but each Preview Environment service would still need a unique custom domain.

SSL is enforced, so adding these unique custom domains would need to wait for the certificate to be issued, which shouldn’t take too long, and should continue to work through the wildcard setup you mentioned.

It may be easiest to try out what you have in mind here and let us know if you come across any issues.

Kind regards

Alan

This topic was automatically closed after 10 days. New replies are no longer allowed.