Free users will get a url like user1.myapp.com
The paid ones will be able to point their domains to my app. And my app will serve specific content based on the domain name.
Is this possible with AppHarbor? Is yes how?
Yes, it is possible to use custom hostnames on AppHarbor.
If you go to the list of your applications on AppHarbor and click the application, you can click "Hostnames" in the navigation shown left. When you add a hostname there will be instructions on how you need to configure the DNS.
The DNS can be configured in two ways:
You can use an A record which will point the domain to the IP address. This is required for root domains (example.com).
You can use a CNAME record which will reference the existing A record AppHarbor maintains, which is better in most cases as you'll not need to maintain DNS yourself.
There is currently no way to add hostnames via the API, although you can easily wrap something up that will issue HTTP requests similar to those of the website.
Related
I have developed an app and make it available via Heroku. Now I would like to add a custom domain name via Ionos however I don't know how to configure it. When using EC2 instances I would configure an static ip address but for Heroku, I don't know what to do. I have checked other post about this but none a precise or recent about what to do.
Thanks for you attention and have a Great day.
Had the exact same issue and here's how I made it work (just specifying I'm not an expert, so take this answer with a grain of salt):
First you'd have to go to Heroku in your app setting and then add the domain name you bought. It's important that you write the host when adding it, like put either www. or *. at the beginning of the domain. It will give you back a DNS target which you will then need to use on Ionos.
Secondly, you'd have to bind this DNS target on Ionos using a CNAME. Just go to your domains, click the one in your list, then open DNS and click Add a record. Choose CNAME and then put www as provider and past the DNS target you copied in target field. Finally, confirm the changes
Wait a few seconds/minutes, navigate to www.yourdomain.whatever and tada!
About static IP address, Heroku made some docs, and that won't work, you'd have to use dynamic ones. So in a nutshell, use CNAMEs instead of A records
Here are some docs if you want to dig more into this
I'm trying to do something pretty simple. I have a domain on godaddy. I want to use Azure Dns to host the domain and connect it to an azure website.
I have it working for www.mydomain.com with the CNAME approach. However I cannot get the root domain, i.e. my domain.com to work with this approach. I tried adding an * A record but that didn't work. I also tried to do CNAME with # but that didn't work either.
Does anyone know how to get the root domain to work? This seems pretty basic but there is no documentation and it is not obvious.
Thanks
Thanks for feedback on this one!
If you need to create the isolated deployment with the static IP, take a look at the Service Environment. The reference first and second.
As you mentioned Azure DNS, i assume that you refer to the Azure DNS service. If so, then it is possible if you have the needed access. Reference for the DNS zones.
Regarding your question about www and CNAME, there are some nuances that should be taken into account and set up. Please refer to that post.
You can set up a DNS 'A' record in Azure DNS to point to the IP address listed for the site in the Web Apps portal (as per the screenshot provided by an earlier answer). The Web Apps team provide the IP address for precisely this purpose, and they know that they can't change these IP addresses because DNS entries would break.
Note that there's no need to use a wildcard record (name = '*'). You should instead use an A record at the domain apex (name = '#', or if using the Azure Portal you can also leave the name blank).
If your hosted your WebAPP in free website plan didn't have any option for adding * A record. You have to Change your web App plan to at least Shared Plan instead of free Plan.
I am developing an app (RoR + Heroku) which allows users create their own websites either using my subdomain (pagename.myapp.com) or using their own domain (pagename.com).
An important point of this is that this option is the key of my business: subdomains are the free plans and custom domains are the paid ones. So I have a table where I store the custom domains of each user and check if this page is active (exists and has paid the quota).
For that I need to give users the capability of point their domain to my servers. All we know that Heroku don't recommend the use of DNS A-Records.
Also I would like to abstract as much as possible this feature to being able to switch my infrastructure (Heroku to AWS) in the future without having to ask all my users to change their DNS Zone. Taking this into account, I think that the best option would be run something like an EC2 proxy (using AWS Elastic IP) which give me the ownership of this IP. This proxy I think that should redirect to proxy.myapp.com, and I would resolve the request in the app level.
Due to I didn't find clear information about that, I am not sure if this hypotesis is the best solution and how to setup the proxy (which type of proxy use? Nginx maybe?).
Said that, I would like to ask recommendations/best practices to solve this "common" feature.
Thanks
What you are wanting to do is fairly straight forward to implement. Your assumptions are correct about setting up the proxy. Nginx or haproxy will both work great for this (I personally would use haproxy). Here are some of the gotchas that you will run into though:
Changing the host header at a proxy server can cause the end web application to generate incorrect links. You can use relative paths to fix this, but it requires that the web application developer to be aware of the environment that they are running in.
user connects to www.example.com (proxy server)
proxy server connects to www.realdomain.com (web app)
the web app has a link for a shopping cart. www.realdomain.com/shoppingcart
the end user clicks on the link but the link is www.realdomain.com/shoppingcart instead of www.example.com/shoppingcart
The cost of the host acting as the proxy server. This can spiral out of control really quickly. For example, do you want redundancy, if so how are you planning on implementing that? Do you plan on having ssl termination? If so you will have to increase the CPU count to accommodate the additional load. Do you want to have a secure connection to heroku from your proxy? If you do then you will need to increase the CPU count for that as well. You may have to add additional ram as well depending on the number of concurrent connections.
Heroku also changes their load balancers regularly. This is important because your proxy service will need to reload the config / update the ip addresses of the heroku instances every 60 seconds. In my experience they may change once or twice a day, but the DNS entry that they use has a 60 second TTL. That means that you should make sure that you are capable of updating your config up to every 60 seconds.
My company has been doing something very similar to this for almost a year now. We use haproxy and simply have it reload the config regularly. We have never had an outage or an interruption to our end users. Nginx is also a very good product. It has built in DNS caching so if you go that route you will need to make sure that you configure it correctly so that the DNS cache TTL is 60 seconds.
Will many of your clients want to use your app on their domain apex? E.g. example.com rather than theapp.example.cpm? If not, I would recommend having them CNAME to proxy.myapp.com which CNAMEs to myapp.herokuapp.com. Then, you can update proxy.myapp.com without customer interruption.
If you do need apex or A record support, you would want to set up Nginx as a reverse proxy for your Heroku app. Keep in mind that if you need HTTPS support for client domains, you will need to do some sort of certificate management on your proxy.
I like the answer dtorgo gave and that he mentioned the TLS termination, which many online tutorials on custom domains don't touch at all.
I'll go into more detail on how to implement the custom domains feature for your SaaS while also handling the TLS/HTTPS.
If your customers just CNAME to your domain or create the A record to your IP and you don't handle TLS termination for these custom domains, your app will not support HTTPS, and without it, your app won't work in modern browsers on these custom domains.
You need to set up a TLS termination reverse proxy in front of your webserver. This proxy can be run on a separate machine but you can run it on the same machine as the webserver.
CNAME vs A record
If your customers want to have your app on their subdomain, e.g. app.customer.com they can create a CNAME app.customer.com pointing to your proxy.
If they want to have your app on their root domain, e.g. customer.com then they'll have to create an A record on customer.com pointing to your proxy's IP. Make sure this IP doesn't change, ever!
How to handle TLS termination?
To make TLS termination work, you'll have to issue TLS certificates for these custom domains. You can use Let's Encrypt for that. Your proxy will see the Host header of the incoming request, e.g. app.customer1.com or customer2.com etc., and then it will decide which TLS certificate to use by checking the SNI.
The proxy can be set up to automatically issue and renew certificates for these custom domains. On the first request from a new custom domain, the proxy will see it doesn't have the appropriate certificate. It will ask Let's Encrypt for a new certificate. Let's Encrypt will first issue a challenge to see if you manage the domain, and since the customer already created a CNAME or A record pointing to your proxy, that tells Let's Encrypt you indeed manage the domain, and it will let you issue a certificate for it.
To issue and renew certificates automatically, I'd recommend using Caddyserver, greenlock.js, OpenResty (Nginx).
tl;dr on what happens here;
Caddyserver listens on 443 and 80, it receives requests, issues, and renews certificates automatically, proxies traffic to your backend.
How to handle it on my backend
Your proxy is terminating TLS and proxying requests to your backend. However, your backend doesn't know who is the original customer behind the request. This is why you need to tell your proxy to include additional headers in proxied requests to identify the customer. Just add X-Serve-For: app.customer.com or X-Serve-For: customer2.com or whatever the Host header is of the original request.
Now when you receive the proxied request on the backend, you can read this custom header and you know who is the customer behind the request. You can implement your logic based on that, show data belonging to this customer, etc.
More
Put a load balancer in front of your fleet of proxies for higher availability. You'll also have to use distributed storage for certificates and Let's Encrypt challenges. Use AWS ECS or EBS for automated recovery if something fails, otherwise, you may be waking up in the middle of the night restarting machines, or your proxy manually.
If you need more detail you can DM me on Twitter #dragocrnjac
I have a sub-domain sub1.primary.com that works correctly. Now I need to setup sub2.primary.com and have it point to the same web application as sub1.primary.com. I tried it as a new A record and a new CName however when I try navigating to sub2.primary.com and expect to see sub1.primary.com I see a completely different application that sits on sub7.primary.com.
I have tried the A record solo, the CName solo, both together, and each instance with and without pointer records. I am using a Windows 2003 Server with IIS 6. I tried googling for an answer and couldn't find any information.
Here is my setup at the moment. I have created a Host (A) record in DNS for sub2.primary.com with an associated pointer record. I have added the sub2.primary.com to host headers of sub1.primary.com. Whenever I navigate to sub2.primary.com it displays sub7.primary.com instead of sub1.primary.com. Which is bizarre because if it were going to default to something I would rather it default to www.primary. com.
I don't know if it matters but the sub1.primary.com is under SSL and so is sub7.primary.com, along with 5 others on a *.primary.com SSL cert.
Each subdomain should have an A record pointing to the same IP. I sounds like this is what you tried first -- if that didn't work, I'd suggest making sure that your web server's vhost configuration is sending sub2.primary.com to the right place.
When IIS hosts multiple websites on the same IP address, it uses the incoming request URLs to guess which virtual site to send the client to.
In other words: you need to configure your host headers to accept both names for the appropriate web site. Microsoft publishes some good how-to documentation here and here, or here is a more detailed explanation.
I have a Default Web Site and another web application (let's call it Application2) inside the Default Web Site in IIS7.
I have 2 registered domain names, let's say www.example.com and www.example.net.
I would like to configure things that when I open www.example.com I get Default Web Site, when I open www.example.net I get Default Web Site/Application2.
www.example.com -> Default Web Site
www.example.net -> Default Web Site/Application2
How can I do that?
First you need to decide if your going to use Name Based or IP Based hosting.
IP-Based uses unique ip's to determine which virtual host it will serve and Name Based will actually use the host header which is sent by your client browser.
So let's see two scenarios:
Scenario # 1 (ONE IP TO SHARE)
You have a server with only one IP, could be either private or public as long as the domains you are serving are properly configured in the dns serving you internally or your client externally (NAT).
I suggest that for the sake of this tutorial you stop the default website. Ok.
You will set up one site in II7 and name it accordingly. Go to the right hand side of the manager and look for "Bindings" under actions menu; making sure you have the new site selected on your left pane. Now under "Site Bindings" select the ip address you will be sharing between the sites (name based hosting). Under "Hostname" enter domain # 1 "www.example.com", hit ok.
Follow the same procedure above with the other domain or domains, making sure they have diferent hostnames and same ip's.
That's it. You will now be able to start those sites and run them at the same time.
The same principle above applies if your using the "Default Site". "Default Site" is just a name MS gave the default created one.
Scenario # 2 (MULTIPLE IP TO SHARE)
If you have either some private or public ip to spare, or at least until you do the exercise the only diference here is that sites you will set up and don't have to specify the "Hostname" per each site, as this is basically done in the DNS zones itself. The sites will respond for any request made to those ip's on port 80 regardless.
When will you need to use multiple Ip's to serve websites. Well it all depends.
Some reasons are: Network Isolation (Security), Applications which don't work well under name based hosting, SSL Certificates Bindings 443(PRE II7), and mostly complete control over site. There are of course more reasons, but I'll let others write a bit also.
Have fun.
Edit... upon further investigation I found that if you can set up multiple sites and run them simultaneously. Just need to stop and start the sites after setting the host values to get them to both run at the same time.
Original post:
The straight-forward way to do this would be to add another application by opening IIS and right-clicking Sites then select Add Web Site. In there you can specify the physical path of Application2 and also set the "host" to "www.example.net" which will filter all those requests to your second site. Any requests that don't match "www.example.net" will still go to the default web site.
That approach will work fine on Windows Server using IIS, but on Vista's IIS7 it won't work since you can only have one site running at a time. To start the second site, you'd first have to stop Default Web Site.