How to use Gatsby with Redwood in a monorepo setup?

Repost from

For many reasons, including static site generation, automatic image optimization and i18n, I prefer to use Gatsby for my marketing / landing pages. (on

However I definitely want to use redwood for the app itself. (on

So I’m wondering what’s the best setup here.

Should I just add another “side” to my redwood app and continue working with yarn workspaces?

- web
- app
- api

Or should I import the full redwood repo in a lerna configuration?

- web (gatsby)
- app (redwood)
   - api
   - webapp

In either case, how do I deal with shared files like the tailwindcss theme etc.

Any guidance here would be greatly appreciated. Thanks

Hi @freddydumont! Thanks for starting this conversation. I do want to clarify one thing to make sure I’m on the same page — there’s a difference between integrating Redwood and Gatsby Vs. using Gatsby for your “www” and Redwood for your “app”.

Gatsby “www” + Redwood “app”

The simplest way to do this is have 2 separate projects (repos). In your deployment configuration (e.g. Netlify dashboard), you’d set the Gatsby project to deploy to something like and the Redwood project to deploy to

And if you wanted to, you could use Lerna (on top of Yarn Workspaces) to create a Monorepo. It would require some config and setup, of course. And I might even recommend your directly structure in this case to be:

- www (gatsby)
  - gatsby folders
  - gatbsy root files
- app (redwood)
  - api/
  - web/
  - redwood root files
other monorepo/lerna config

Both Netlify and Vercel allow you to deploy multiple sites from a Monorepo.

Gatsby + Redwood integration

If you’d like to swap the Redwood Web side for Gatsby (e.g. replace the web/ files in a Redwood Project with a Gatsby project), it’s conceivably possible although you’d be the first I know of to try it. I’m very curious how it might work. Or even if it would work.

Since the Redwood API is GraphQL, you should be able to consume it with Gatsby although I’m not familiar with how Gatsby works at this level. (Note: you wouldn’t have to integrate the two for Gatsby to use a Redwood API — you could do this in the first example above as well.)

You’d need to manually handle the CLI for local dev and build with custom package.json scripts, which I don’t think would be too bad.

But you’d most likely lose Redwood generators and Cells – you could try to use the required imports for Cells but I think it would take extra config to make it work with Gatsby’s data fetching (if it even worked at all).

So I’m not sure what you’d gain in doing this other than having fully pre-rendered pages/routes across both your “www” and “app”. You’d have access to the Gatsby plugin ecosystem throughout as well. But, again, this assumes integration like this is even feasible.

Anyone else have any ideas about how, or even why, and integration could and should work?


I didn’t consider replacing the web side with Gatsby, more like adding a Gatsby side to the existing setup. Kinda like you could eventually add a react-native side.

Seems like the straightforward solution is rather to deploy to different subdomains like in your first example.

Thanks for your answer @thedavid!

1 Like

Ah, makes sense. There’s the general concept of Redwood Sides (currently api/, web/) that will one day become extensible. Effectively they are yarn workspaces (which is why you can add more workspaces now, e.g. lerna example above). But there are additional concerns regarding core Redwood config/babel/webpack and CLI commands.

All possible as is. Just not convenient.


Keep us posted!

I’ve grappled with this a few times, and IMHO, it best not to replace the web side even if you’re using Gatsby for the front end.

A very typical setup would probably be:
A. gatsby for landing page, FAQs, contact pages, privacy policies etc.
B. Redwood for the actual app, where most of the pages are dynamic
C. Gatsby can pull data from RW using graphql where required

My reasoning for this is simple - Gatsby excels at certain things - i.e. static-ish content. Redwood excels at others i.e. dev experience and dynamic data driven apps. If you only need one of these things, and and not the other, probably best to stick to the tool that’s best for the job.

To each their own though, and please do post here if you find a better way, would be more than happy to be proven wrong here!

1 Like

I tried to make it work with a few different approaches, but the best is to stick to redwood for the whole stack.

In the end, the benefits of Gatsby aren’t worth the hassle of maintaining two different frameworks. What I miss the most is automatic image optimization though. Not sure how to do that in a SPA.

1 Like

Some good news potentially @freddydumont - I can’t say I’ve tested it thoroughly or anything, but I think netlify will automatically optimise images for you (its in the post processing section).

Alternatively worth a look into

Webpack is powerful but can be super annoying. Here’s another thread (for a completely unrelated problem) where I walked through adding to the existing RW webpack config CORS issues when developing locally against a separate API server

@danny @freddydumont I think image optimization is definitely worth a discussion regarding Performance and the Redwood roadmap. Might be worth organizing research/ideas in a GH Issue.

No pressure and mostly thinking out loud.