Skip to content
Hostgrid

How Hostgrid Works for SaaS Products

If you’re building a SaaS product, at some point you’ll likely run into this requirement:

“Can customers connect their own domain?”

It sounds simple at first. But once you support even a handful of customers, it quickly turns into infrastructure work.

Hostgrid exists to handle that layer for you.

The real problem behind custom domains

Section titled “The real problem behind custom domains”

Supporting custom domains isn’t just about “pointing a domain somewhere.”

Behind the scenes, you end up dealing with:

  • DNS setup and verification for every customer
  • SSL certificates for every domain
  • HTTPS enforcement and renewals
  • Routing requests to the correct application or tenant
  • Handling domain changes and edge cases safely

This is fine for a few customers. It becomes painful very quickly as you scale.

Most SaaS teams don’t plan for this early — until it starts breaking onboarding or eating engineering time.

What Hostgrid actually does

Section titled “What Hostgrid actually does”

Hostgrid sits in front of your application and handles all of that domain infrastructure.

You connect your SaaS once, and Hostgrid takes care of:

  • Verifying that a customer owns their domain (via DNS)
  • Issuing and renewing SSL certificates automatically
  • Serving traffic over HTTPS
  • Routing requests to your application
  • Applying optional routing rules if you need them

Your application doesn’t change. You don’t rewrite your backend. You don’t manage certificates.

A simple mental model

Section titled “A simple mental model”

Think of Hostgrid as the layer between customer domains and your SaaS.

customer.com
      │
      ▼
  Hostgrid
      │
      ▼
your-saas.com

Every request passes through Hostgrid before it reaches your app.

It works with different SaaS setups

Section titled “It works with different SaaS setups”

Not every SaaS is built the same way, and Hostgrid doesn’t force you into one structure.

1. Shared multi-tenant apps

Section titled “1. Shared multi-tenant apps”

Many SaaS products use a single application with tenant-based routing:

your-saas.com/customer1
your-saas.com/customer2

In this case, multiple domains can point to the same upstream:

customer1.com → your-saas.com
customer2.com → your-saas.com

Your app figures out which customer is being served.

2. Subdomain-based SaaS

Section titled “2. Subdomain-based SaaS”

Other products isolate customers using subdomains:

customer1.your-saas.com
customer2.your-saas.com

Here, each domain can map to a different upstream or tenant entry point:

customer1.com → customer1.your-saas.com
customer2.com → customer2.your-saas.com

Hostgrid supports both approaches. You decide how your system is structured.

What happens when a customer adds a domain

Section titled “What happens when a customer adds a domain”

When a customer connects their domain, Hostgrid handles the onboarding flow:

  1. You show them DNS records to add
  2. Hostgrid verifies domain ownership
  3. An SSL certificate is issued automatically
  4. HTTPS is enabled for the domain
  5. Traffic starts flowing to your application

This is a one-time setup per domain.

What happens on every request

Section titled “What happens on every request”

Once a domain is active, visitors always interact with the custom domain itself (for example customer1.com).

The browser URL never changes. Hostgrid acts as a reverse proxy between the visitor and your application.

That means:

  • The visitor requests customer1.com
  • Hostgrid fetches data from your application
  • The response is returned back through Hostgrid
  • The user still sees customer1.com in the browser

Request flow

Section titled “Request flow”
Visitor
   │
   ▼
customer1.com (custom domain)
   │
   ▼
Hostgrid
   │
   ├── Applies request rules (optional)
   │
   ▼
Your Application (upstream)
   │
   ├── Response generated
   │
   ▼
Hostgrid
   │
   ├── Applies response rules (optional)
   │
   ▼
Visitor (browser shows customer1.com)

Reverse proxy behavior

Section titled “Reverse proxy behavior”

Hostgrid does not redirect users to your application.

Instead, it:

  • receives the request on the custom domain
  • forwards it to your upstream
  • receives the upstream response
  • optionally modifies it
  • returns it back to the same domain

From the user’s perspective, everything happens on customer1.com.

Where rules apply

Section titled “Where rules apply”

Rules can modify both sides of the request lifecycle:

Request side (before upstream)

Section titled “Request side (before upstream)”

Rules can:

  • rewrite the path
  • add or remove headers
  • block or redirect requests
  • change request metadata sent to your application

Response side (before visitor)

Section titled “Response side (before visitor)”

Rules can:

  • add security headers
  • modify response headers
  • adjust caching behavior
  • return custom responses in some cases

What you still own

Section titled “What you still own”

Hostgrid doesn’t replace your SaaS — it just removes the domain infrastructure burden.

You still control:

  • Your application logic
  • Multi-tenancy model
  • Data and permissions
  • UI and branding
  • Business logic

What Hostgrid removes from your stack

Section titled “What Hostgrid removes from your stack”

Without Hostgrid, you’d typically need to build and maintain:

  • A certificate management system
  • A DNS verification workflow
  • A reverse proxy layer
  • Per-domain routing logic
  • Edge request handling infrastructure

Hostgrid replaces all of that with a managed layer.

The takeaway

Section titled “The takeaway”

If your SaaS supports custom domains, you don’t need to build the infrastructure behind it yourself.

Hostgrid handles the messy parts — DNS, SSL, and routing — so you can focus on your product.

Next steps

Section titled “Next steps”

If you’re setting things up, these pages will help: