Learn how a custom domain for your Hub works if you want to use a subdirectory (like www.mycompany.com/resources).
Before You Begin
- In this article, we'll assume that you already know what a custom domain is and have decided to set one up. If you're not sure what a custom domain is and why you'd want to use it, see this article for help.
- Hosting a Hub on a subdirectory is an advanced option that may not work with your website as it is currently set up (or would require changes to your website hosting to work). To understand whether this option will work for you, you should have some familiarity with how your website hosting is set up, or have access to a resource who can help you get the necessary information.
About Hosting Your Hub on a Subdirectory
If you want to use a custom domain with your Uberflip Hub, there are two options: you can host your Hub on a subdirectory, or on a subdomain.
This article will provide an overview of the setup process if you have chosen to use the subdirectory option. In other words, it will explain how you can make your Hub accessible under a URL that looks something like www.mycompany.com/resources.
Compared to using a subdomain, the process for using a subdirectory to host your Hub is significantly more technical in nature. To explain how it works and how to set it up, we will need to look at web server technology and related concepts. That said, this article is specifically intended for a non-technical audience, so people with no technical background should be able to follow along without difficulty.
Why Hubs on Subdirectories Are More Complex
Although the actual setup processes for subdirectories and subdomains are completely different, these are really just different ways of achieving the same goal. In both cases, what we are doing is serving up a Hub as if it's part of your website, even though it's hosted on Uberflip's servers. So why are subdirectories more complicated to set up?
When you go the subdomain route, we're able to take advantage of a web feature called CNAME record to achieve our goal. This quite literally makes it look like you're visiting one website while you're actually getting the content from another website. It's a function that's ready-made to do exactly what we need it to do, and it's very easy to set up.
The problem is, CNAME records only work on subdomains — they can't be used with subdirectories. So if you want your Hub's URL to look like www.mycompany.com/resources (rather than resources.mycompany.com), an alternative solution is required. To host your Hub on a subdirectory, you need to use a reverse proxy instead.
What a Reverse Proxy Does
To understand what a reverse proxy does, we first need to look at what's happening under the hood when you visit a website. In a nutshell, a client (i.e. a user visiting a webpage with their browser) sends a request over the web to a server, and the server retrieves the requested resource (i.e. the webpage and all the content on it) and sends it back to the client.
This system can also contain other elements, like proxies. A proxy (technically a proxy server, but we'll just say proxy for short) is an intermediary that sits between the client and the server. At the most basic level, a proxy takes requests from the client and sends them on to the server, then takes the resources returned by the server and passes them back to the client.
Proxies can be used by either clients or servers. When a proxy is used by a server, it's called a reverse proxy. This is the type we're interested in, because a reverse proxy can pass requests to more than one server, and can selectively send requests to different servers based on certain criteria.
This ability to route incoming requests is useful, because it means you can use it to direct requests for a subdirectory the same way you'd use a CNAME record on a subdomain. All you have to do is set up a reverse proxy in front of your web server, then create a rule on it that says: "pass through all other traffic to my regular server, but whenever you get a request for this specific subdirectory, send it to Uberflip's servers instead".
The result is that for all regular traffic to your website (i.e. if someone asks for any page other than your Hub's subdirectory), the proxy simply sends the requests through to your normal servers:
But whenever a request comes in for the particular subdirectory where your Hub lives (e.g. mycompany.com/resources), the proxy sends it to Uberflip's server, which seamlessly returns your Hub content to the client:
As far as the client is concerned, they went to mycompany.com/resources and got your Hub — they have no idea that it came from a different server than all the other pages on your website. And there it is: with the help of a reverse proxy, we can make it look like your Hub is part of your website.
Implementing a Reverse Proxy
Here's where things get a little more complicated. So far, we've looked at how it all works in the abstract, but in more practical terms, there are actually several different ways to use a reverse proxy with your website.
Let's begin by taking a general look at the two main ways you can implement a reverse proxy:
Option 1: Proxy Server/Load Balancer or Reverse Proxy Module
What it is: As we described above, a reverse proxy server is a server that sits between the web and one or more web servers. It takes client requests and forwards them on to the web server(s), then returns the responses to the clients.
A load balancer is simply a specific type of reverse proxy. The term refers to a particular application where the reverse proxy is used to distribute the workload of high-traffic websites between multiple servers.
A reverse proxy can also be implemented as part of the main web server, usually in the form of a module. The effect is exactly the same as having a dedicated reverse proxy server; the only difference is that it's part of the web server, rather than a separate entity.
How it works with your Hub: With a reverse proxy in place (whether it's implemented as a separate system, a load balancer, or an integrated module), you can configure it to route certain requests to specific servers, i.e. requests for your Hub subdirectory to Uberflip's server.
Examples: Commonly used reverse proxies/load balancers are HAProxy and NGINX. An example of a reverse proxy module on a web server is mod_proxy on Apache HTTP Server.
Option 2: Content Delivery Network (CDN)
What it is: A Content Delivery Network is a service which maintains a network of proxy servers in various geographic locations, and can deliver your website to a client from any of those servers. There are various use cases for CDNs, but the most common one is based on the idea that a website will generally load faster when the server is physically closer to the client. By making sure there is a server fairly close to any possible client, CDNs can optimize load times for the websites they deliver.
How it works with your Hub: At its heart, a CDN is essentially a network of proxy servers. So, like any reverse proxy, most offer the ability to selectively route route requests.
Examples: Major CDNs include Amazon CloudFront, Akamai, Cloudflare (Enterprise), Limelight, etc.
Which Reverse Proxy Option Should I Choose?
The bottom line is that you need to implement a reverse proxy of some sort. How you choose to do this will depend on your specific circumstances, and we can't provide a definitive, one-size-fits-all answer.
However, this is our general recommendation: if you don't currently have reverse proxy functionality on your web server, use a CDN. Here's why:
- It's simple: With no other reverse proxy functionality currently in place, it's typically the simplest of the options to add to your web hosting setup.
- It works: We have experience with using a CDN for this purpose (CloudFront, specifically), and we know it works well.
- It's faster: By their nature, CDN servers are virtually always located closer to any given client than your own servers, and in most cases can offer faster load times for your Hub than a proxy server.
- Cost: Some CDNs offer a free service tier, so if your website is below a certain amount of volume, using a CDN may come at no extra cost. (For example, CloudFront's free tier includes 50 GB data transfer and 2 million requests per month.) By comparison, adding a dedicated reverse proxy to your web server would likely be more expensive.
- Additional benefits: Aside from allowing you to host your Uberflip Hub on a subdirectory, you also get the primary benefits of using a CDN with your website, including generally faster load times for end users, load balancing, DDoS attack protection, etc.
We strongly recommend going with a CDN if you want to host your Hub on a subdirectory, but that doesn't mean you have to use one. If you do already have some type of reverse proxy functionality in place, you can certainly leverage that instead.
To help make your decision, here are some questions to ask your website/technical team:
- Does our web server use a load balancer or reverse proxy server like HAProxy or NGINX?
- Yes: You can consider using it to direct requests for your Hub subdirectory.
- No: Proceed to next question.
- Does our web server have reverse proxy/gateway capabilities such as Apache's mod_proxy (or equivalent)?
- Yes: You can consider using it to direct requests for your Hub subdirectory.
- No: Proceed to next question.
- Do we use a CDN with our website?
- Yes: Use your existing CDN to direct requests for your Hub subdirectory.
- No: Add a CDN to your web hosting setup.
Next Steps
Still not sure whether you should use a subdirectory custom domain? Check out this article, which outlines a few questions you can ask to determine if it's the right choice for you.
If you've decided that you want to set up your Hub on a subdirectory custom domain, read our guide for setting up your Hub on a subdirectory custom domain to learn about the process and get started: