Redirect to other Netlify apps using subdirectories

Netlify site: https://amseeyou.netlify.app

My main goal is to present a different Netlify app using a subdirectory without changing the URL.

For context, I have a few sites deployed:

  1. https://amseeyou-v1.netlify.app
  2. https://amseeyou-v2.netlify.app
  3. https://amseeyou-v3.netlify.app

I want to display https://amseeyou-v1.netlify.app on https://amseeyou.netlify.app/v1 along w/ the other two versions. I mainly followed this Support Guide: [Support Guide] Can I deploy multiple repositories in a single site? and this doc: Rewrites and proxies | Netlify Docs. However, I can’t seem to figure it out.

You’ll want to deploy the blog as a subdirectory of the published site (that is: not in the root directory).

This part was confusing. How do I deploy my “blog” (i.e. versioned site) as a subdirectory of the “published site” (i.e. the main site) if they’re two different sites?

Here are the commits I tried on my repo, labelled as Test _redirects attempt #<num> Commits · kndshein/AmSeeYouToo · GitHub. None of them worked. The only thing I could get it to work is to redirect Am See You to https://amseeyou-v1.netlify.app, BUT the url changed. I’d like the URL to stay the same.

P.S. I’m currently deploying four sites by targeting individual branches – is there a better way to achieve the above task? (Different versions of the app in one app, branched w/ subdirectory)

Much appreciated.

To do this, you want the 200 as a rewrite/proxy, not a 301 (or blank, which defaults to 301):

You can see it’s currently working as per what you have in your latest commit:

/v1/* https://amseeyou-v1.netlify.app
/v2/* https://amseeyou-v2.netlify.app 200
/v3/* https://amseeyou-v3.netlify.app 200!

v1

https://amseeyou.netlify.app/v1/ is doing a 301 to https://amseeyou-v1.netlify.app/

v2

https://amseeyou.netlify.app/v2/ is serving the files from https://amseeyou-v2.netlify.app

However it’s broken, because none of the assets are found:

This is because they’re root relative URL’s:

Without the URL changing, while the HTML content has been served from amseeyou-v2.netlify.app the browser is trying to load the assets from amseeyou.netlify.app and they quite simply do not exist there.

v3

https://amseeyou.netlify.app/v3/ is serving the files from https://amseeyou-v3.netlify.app

It suffers the same issue as v2 with the same explanation.


Possible solutions are:

  • Changing the asset references on the sub-sites to be absolute URL’s.
  • Adding additional rewrites so the assets requested on amseeyou.netlify.app resolve to the correct location.
1 Like

Aha! Thanks. Glad to know a few of the 9 permutations I tried were working as intended. Thanks for your time in answering!

I’ve marked the above post as the solution as it directly answered the question, however I’m a bit stumped on the implementation of the solutions.

Changing the asset references on the sub-sites to be absolute URL’s.

I attempted this solution – I changed the base path for https://amseeyou-v3.netlify.app to https://amseeyou-v3.netlify.app. And… it partially worked. The JS seems to be blocked by CORS. Would you happen to have a tip on how I should continue here? The hosted site (i.e. https://amseeyou-v3.netlify.app) isn’t a server, so I’m not sure where I would set it to allow cross origin…

Adding additional rewrites so the assets requested on amseeyou.netlify.app resolve to the correct location.

This seems more straightforward in some respect, however, I’m not sure where to start. Additionally, my intuition tells me that I’m bound to run into CORS here as well.

I believe you could solve this with 3.2.1 in this guide:


It would be very straightforward if each site was requesting its assets from an easily identified sub-folder, something like:

/assets-v1/* https://amseeyou-v1.netlify.app/assets-v1/:splat 200!
/assets-v2/* https://amseeyou-v2.netlify.app/assets-v2/:splat 200!
/assets-v3/* https://amseeyou-v3.netlify.app/assets-v3/:splat 200!

But they currently aren’t, they’re more generic (/assets/, /static/assets/ etc) so they can’t be blanket rewritten with a wildcard, and they also consist of generative sha’s so manually specifying each individual asset would break when your code changes.

Forgot to mention, you wouldn’t run in to CORS with this, in the same way that people use it proxy an external API to avoid CORS (as per https://docs.netlify.com/routing/redirects/rewrites-proxies/#proxy-to-another-service).

1 Like

Sweet! I got it to work! For my future self and for others who are in a similar boat, here’s what I ended up doing:
For context, this situation was slightly complicated due to two different bundlers/compilers (webpack from CRA, and esbuild from Vite). I didn’t want to bother updating webpack, and wanted the path of least resistance as this feature is simply for archiving purposes. So, my solution here is a mix of both of the items detailed above:

For amseeyou-v1 and amseeyou-v2, which are CRA apps, I ejected the bootstrapped react-scripts, and renamed /static to /static-v<num>. I couldn’t figure out how to set absolute pathing and quite frankly, the ejected config was complicated enough, I didn’t want to bother.

For amseeyou-v3, which is built using Vite, I added base: 'https://amseeyou-v3.netlify.app' in vite.config.ts in defineConfig(). Ironically, I couldn’t figure out how to set relative pathing here. Setting the base as /assets-v3 didn’t work as the value just simply got prepended, which was not helpful.

In all of three repos, a netlify.toml was added in the root w/ the same info:

[[headers]]
  for = "/*"
  [headers.values]
    access-control-allow-origin = "https://amseeyou.netlify.app"

So, w/ the mixed solution, the _redirects in the main repo had to follow the mixed approach (notice that the v3 didn’t need to redirect the static files):

/v1/* https://amseeyou-v1.netlify.app 200!
/static-v1/* https://amseeyou-v1.netlify.app/static-v1/:splat 200!
/v2/* https://amseeyou-v2.netlify.app 200!
/static-v2/* https://amseeyou-v2.netlify.app/static-v2/:splat 200!
/v3/* https://amseeyou-v3.netlify.app 200!

Cheers. Thanks a ton, Nathan!

@kndshein No problem at all, glad I could help!

Again for anyone else encountering this, if you have very few assets that won’t change filename (don’t contain SHA’s etc), it’d be perfectly valid to just do a rewrite per asset.

In which case you usually wouldn’t require any changes to your site config/code.