Use DNS to host in different Render app several subdomains (Rails)

1

I’m a bit Ruby on Rails rookie and would like to aply the idea of Building Awesome Rails APIs: Part 1 | Collective Idea.

I want to have one codebase on github, a ruby on rails app but scale independently the web app, the api, the admin dahsboard, etc using Rails namespace and DNS. It means I have one app connected to render and they’d need to push to different machines.

If your API gets hammered, you can point the DNS for the API subdomain to another set of servers and scale it independently of your main app.

Is it possible to use DNS so that api.example.com points to a certain Render Service, app.example.com to another Render Service and www.example.com to another?
This way I’d hope if each render srver has autoscale, I could scale up and down those three “bounded/seperate” needs from a single codebase, just suing DNS and Rails namespaces to scale independently each stuff.

In a way i could put this usecase like this: 1 monorepo to deploy to 3 Render.com Services on the same Domain (example.com) thanks to some “procfile”, each serving a different subdomain api/example.com, admin.example.com…

Maybe Render has some type of Procfile so that you can use one repo to deploy to multiple apps such as Heroku Multi-procfile (see here and here)

Hope I’m clear enough and thanks for any help,

Michael

Note: I’ll use a custom domain plugged to Render and Clouflare

2

Hey Michael,

From your description, I believe this will work well on Render.

If you have three different applications that you want to scale independently, you would create three services on Render, each using the same repository. You can use different build and start commands to run the different applications for each service. We support horizontal scaling for stateless apps (ie. apps with no Render disk attached), so you can scale each service as needed. We also have autoscaling available in early access. Let me know if you would be interested in that.

As for DNS: Each of your services will be given a unique subdomain on onrender.com. You can create DNS records to direct traffic from your custom domains to the individual Render services. See our docs for details.

We also have Infrastructure as Code available to manage all of your services from a single file. When you use IaC, you can also take advantage of preview environments to create copies of your production environment with every new pull request.

Let me know if this fully answers your question.

4

thanks, it’s great, Render is really flexible.

Just a clarification: you say

“You can create DNS records to direct traffic from your custom domainS to the individual Render services”

but I’d like all Services to be for the same custom domain. For example it would be myapp.com which would be behind the scene sth like nice_rendersubdomain.render.com
then the repo would deploy the app to :

  • api.myapp.com which would be i think api.nice_rendersubdomain.render.com
  • admin.myapp.com which would be admin.nice_rendersubdomain.render.com
  • and so on…

My 2 questions is

  • is it ok if it’s all pointing to the SAME domain that is myapp.com (=nice_rendersubdomain.render.com)
  • is it ok if the subdomains are “2nd level depth” meaning if you take the url of render api.nice_rendersubdomain.render.com it’s the subdomain of the subdomain for render.com

Just making sure it works this way.
Thanks

5

Sorry I wasn’t entirely clear. Yes, you can use a single custom domain and point subdomains at different Render services by creating CNAME DNS records (described in the custom domains documentation). For example, you can have:

api.myapp.com -> your-api-service.onrender.com
admin.myapp.com -> your-admin-service.onrender.com

You can’t create additional subdomains of your service’s onrender subdomain (eg. example.your-api-service.onrender.com), but you can set up any subdomain of your custom domain to forward traffic to your Render service. It shouldn’t be necessary to create subdomains of your service’s onrender subdomain, but let me know if there is a use case your are trying to support with this setup.

6

this seems perfect for our need.

Just curious about authentication in relaiton with these subdomains.

  • Let’s assume a anonymous visitor comes to www.myapp.com (which behind the scene via DNS points to main-public-site-for-visitors.onrender.com ).
  • Then he clicks on ‘sign up’ button and goes to www.myapp/sign-up (which behind the scene via DNS points to main-public-site-for-visitors.onrender.com/sign-up ).
  • Then he signs up and with Rails it creates a session for the visitor who is now signed-in thanks to Rails authenticaiton gem Devis on www.myapp.com so that means he’s loggeidn with an antuthenticated session on the Service main-public-site-for-visitors.onrender.com
    But the issue is that once logged-in, the visitor is sent via the app logic to the Admin panel URL on the other Service your-admin-service.onrender.com …which is another server on Render so his sessions does not exist there. He won’t be logged-in which is a major issue. Am I wrong ?

Does that mean that I should be careful and always put all the subdomain sharing authentication on the same Render Service. In this specific case i should make sure when setting up the DNS that www.myapp.com and admin.myapp.com BOTH send to the same Render service common-render-service.onrender.com ?

Or am I wrong and different Render service can easily share sessions / authentications ?(note: I don’t want to set up SSO and complex cross server authentication if it’s complex).

Thanks
Michael

10

Hi @Michael_Reisner. On the browser side, you can share cookies across subdomains. On the server side, the main service and admin service can securely communicate with each other within the private network Render creates for you. There are a number of ways to achieve this, like putting session data in a database or making requests between the two services.

11

Hi @jake & @david,

It shouldn’t be necessary to create subdomains of your service’s onrender subdomain, but let me know if there is a use case your are trying to support with this setup.

Actually, I am doing what you suggested to Michael. We have several services, and we have subdomains that point to that services.

That being said, it does not fit our needs with “preview envs” and our monolith architecture. Indeed, I have an internal proxy that forward the request depending on the path and/or the host and/or the domain and/or … to the right Endpoint in my application

For example, I have 1 application that is able to forward the request depending on the subdomain to the right internal Endpoint:

  • myservice1[dot]mydomain[dot]com → my-app[dot]onrender[dot]com
  • myservice2[dot]mydomain[dot]com → my-app[dot]onrender[dot]com

The proxy catches the subdomain part and knows what to do. If I want to use the “preview envs”, I am stuck because when I will deploy a branch, the subdomain will be “pr-105-my-app[dot]onrender[dot]com”. Unfortunately, It means that I cannot test the service 1 and service 2 with “preview envs” :frowning: In this case, when a proxy is behind the applications/services, a sub subdomain is the way to go:

  • myservice1[dot]pr-105-my-app[dot]onrender[dot]com
  • myservice2[dot]pr-105-my-app[dot]onrender[dot]com

To fix this, we are deploying multiple services like you recommended, and we are changing our way to deploy because render.com as this limitation, and it costs us more without any added value. Another consequences is that we cannot deploy the whole ecosystem with one PR and our monolith :frowning:

I precise that it is ONLY because I cannot use sub subdomain with “preview envs” that we have to tweak the way we deploy and so, our dev environment is different from the production environment, that is different from the preview envs. If i choose to get rid off this feature (preview env), it’s easy to do because I do not have issue with sub domains as I managed the custom domains. But in that case, we believe that we miss one of the key feature of render.com

Maybe you have something to propose that could help us?

PS: As a new user a cannot post more than 2 link in a post, sorry for the [dot] :wink:

EDIT: Another use case us custom subdomain by user. “customer[dot]myapp[dot].com”. How can I test it with preview envs?

12

@malian We have customers using our API to add custom domains to preview apps at the time they are built - here’s a script I wrote Add custom domain to Render preview environment app · GitHub that does this using a ‘known’ format for the resultant domains,

Regards,