Feature Request: Allow Preview URLs on Custom Subdomains (Not Just workers.dev)

[rushab-agi]

Describe the solution

We're migrating from Cloudflare Pages to Workers (using Vite) and need preview URLs to run on custom subdomains (e.g. preview.branch.example.com), not just workers.dev.

Right now, preview environments are limited to workers.dev, which breaks workflows that rely on domain-specific logic, cookies, and branch-based URLs.

Request:
Please add support for preview deployments on custom subdomains, or let us know if this is planned or possible in the future.

Thanks!

[NWBY]

Would be very interested in this as well!

[eversteadweb]

Yes, we would really appreciate this functionality when sharing previews with clients!

[scottmessinger]

I was pretty excited about cloudflare workers, but this is a blocker. How can we migrate off vercel if the preview urls break all our images (as the Image API can't be enabled for the accountname.workers.dev zone)? This is both really frustrating and a really puzzling product choice.

It has me wondering if I've misunderstood what CF workers should be for. Given the purchase of Astro (and support of other frontend frameworks), I've been assuming that CF wanted to have something competitive with Vercel and wanted people to deploy their react websites on CF workers. But, am I wrong here? Is CF intending for workers to be APIs and would encourage people to look at other services if they want to deploy websites? Or, maybe I'm right about websites, but wrong about CF's committement to their Image API? Maybe CF wants us to use imgix or other sites and not their image API?

This might not be CF's fault and just my misunderstanding of their positioning and intended use case.

[ericmatthys]

I have some projects that have worked around this limitation using another worker project to serve as a proxy. We have a GitHub Action that manages deployments and posts links to builds using the custom subdomain. This is in standalone project that handles requests to something like *.preview.example.com and then proxies the request to the underlying worker deployment. Here's an example:

const proxyRules = [
  {
    pattern: /^([^.]+)\.preview\.example\.com$/,
    replace: '$1-example-preview.example-dfw.workers.dev',
  },
];

function getProxyTarget(hostname: string): string | null {
  for (const rule of proxyRules) {
    if (rule.pattern.test(hostname)) {
      return hostname.replace(rule.pattern, rule.replace);
    }
  }

  return null;
}

function rewriteLocationHeader(
  response: Response,
  originalHost: string,
  targetHost: string,
): Response {
  const location = response.headers.get('Location');

  if (!location || !location.includes(targetHost)) {
    return response;
  }

  const redirectResponse = new Response(response.body, {
    status: response.status,
    statusText: response.statusText,
    headers: response.headers,
  });

  redirectResponse.headers.set(
    'Location',
    location.replace(targetHost, originalHost),
  );

  return redirectResponse;
}

export default {
  async fetch(request: Request): Promise<Response> {
    const url = new URL(request.url);
    const originalHost = url.hostname;
    const targetHost = getProxyTarget(originalHost);

    if (targetHost) {
      const proxyUrl = new URL(request.url);
      proxyUrl.hostname = targetHost;

      const headers = new Headers(request.headers);
      const originalOrigin = headers.get('Origin');

      if (originalOrigin) {
        const originUrl = new URL(originalOrigin);

        if (originUrl.hostname === originalHost) {
          originUrl.hostname = targetHost;
          headers.set('Origin', originUrl.toString());
        }
      }

      const modifiedRequest = new Request(proxyUrl.toString(), {
        method: request.method,
        headers,
        body: request.body,
        cache: request.cache,
        credentials: request.credentials,
        integrity: request.integrity,
        keepalive: request.keepalive,
        mode: request.mode,
        redirect: request.redirect,
        referrer: request.referrer,
        referrerPolicy: request.referrerPolicy,
        signal: request.signal,
      });

      const response = await fetch(modifiedRequest);

      if (response.status >= 300 && response.status < 400) {
        return rewriteLocationHeader(response, originalHost, targetHost);
      }

      return response;
    }

    return new Response(`Unexpected domain "${url.hostname}"`, { status: 400 });
  },
};

[billzhong]

Any progress on this?

[emensch]

Hi folks, this is a blocker for my team. If this feature existed, we'd migrate :)

[jamestalmage]

This is a pain-point for developing against auth endpoints... We have developed work-arounds, but they are cumbersome.

[flayks]

This would be great, coming from Pages this is a big loss… not we need to do another worker for a different branch if I'm not mistaken? That's really not ideal when we had the option before.