Is there such thing as a “multi-tenant” Astro app?

[finleyjb]

Is there a way to make an Astro app that can handle multiple domains? Or is Astro single-domain only?

EDIT: I guess I found an answer, but I don’t see any official documentation for this. Plus I’m looking to handle arbitrary domains.

[florian-lefebvre]

The article is pretty great. As far as I know, there's nothing built-in but yeah SSR allows you to do anything. I think domain multi-tenants is often something to tackle on the host site.

Sorry I can't provide a better answer but maybe someone else has an idea!

[karenrebecag]

Yes. With on-demand rendering (an adapter + output: 'server', or export const prerender = false on the routes involved) one Astro app can serve any number of domains, including arbitrary customer domains. It splits into two parts: resolving the tenant inside Astro, and getting the domains to point at your deployment.

1. Resolve the tenant from the host in middleware

// src/middleware.ts
import { defineMiddleware } from 'astro:middleware';
import { getTenantByHost } from './lib/tenants'; // your DB / KV lookup

export const onRequest = defineMiddleware(async (context, next) => {
  const tenant = await getTenantByHost(context.url.hostname);
  if (!tenant) return new Response('Unknown site', { status: 404 });
  context.locals.tenant = tenant;
  return next();
});

Pages then read Astro.locals.tenant to pick the theme, content, etc. (type it in src/env.d.ts under App.Locals).

The gotcha: security.allowedDomains. Behind most hosts/proxies the real domain arrives in X-Forwarded-Host, and since Astro 5.14.2 that header is ignored unless it matches security.allowedDomains, to prevent host-header injection. If you skip this, context.url.hostname can come back as the proxy/internal host instead of the customer's domain:

// astro.config.mjs
export default defineConfig({
  output: 'server',
  security: {
    allowedDomains: [
      { hostname: '**.yourplatform.com', protocol: 'https' },
      // For arbitrary customer domains, [{}] trusts any host.
      // Only do that behind a proxy you control, and still reject
      // unknown hosts in middleware like above.
    ],
  },
});

2. Point arbitrary domains at the deployment (this is the host's job)

Astro doesn't handle it; it's DNS + TLS on your platform, and it's the part the article can't cover for arbitrary domains:

• Vercel: add customers' domains to the project programmatically through the REST API (their "Platforms" starter is built on this) and use a wildcard domain for *.yourplatform.com.
• Cloudflare: "Cloudflare for SaaS" custom hostnames issue certs for customer domains that CNAME to you.
• Netlify: domain aliases work for a known list. For truly arbitrary domains Vercel or Cloudflare for SaaS are the smoother path.

Your onboarding flow then becomes: customer adds a CNAME → you register the hostname with the host API → you store hostname → tenant in the DB the middleware reads.

One last thing: pages that differ per tenant can't be prerendered at build time, since the build doesn't know the host. Keep those on-demand, and if you cache them at the CDN, make sure the cache key includes the host.