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

I’m a bit Ruby on Rails rookie and would like to aply the idea of collectiveidea.com/blog/archives/2013/06/13/building-awesome-rails-apis-part-1.

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

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.

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

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.

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

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.