Connecting Netlify CMS with RedwoodJS

Hey Y’all! :wave:

I’ve been playing with Redwood for the past few days and have to say that Iimageit.

Here is my HOW TO on connecting :electric_plug: Netlify CMS and RedwoodJS. They have docs, but it’s not clear with Redwood’s file structure where to put everything.

  1. In web/public make a new file called ‘admin’.
    Screen Shot 2020-08-07 at 3.20.16 PM

  2. Add two files to web/public/admin → 'config.yml and index.html

  3. in index.html add the following HTML:

<!doctype html>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <script src=""></script>
    <title>Content Manager</title>
    <!-- Include the script that builds the page and powers Netlify CMS -->
    <script src="^2.0.0/dist/netlify-cms.js"></script>
  1. In your terminal (make sure you are in the RedwoodJS root folder):
yarn workspace web add netlify-cms --save
  1. Configure your config.yml file in the web/public/admin folder:
  name: git-gateway
  branch: master # Branch to update (optional; defaults to master)

  publish_mode: editorial_workflow
media_folder: "web/src/assets/uploads" # Media files will be stored in the repo under web/src/assets/uploads
public_folder: "uploads" # The src attribute for uploaded media will begin with /uploads

  - name: "post"
    label: "Blog Post"
    folder: "content/posts"
    create: true
    slug: "{{slug}}"
// etc.

:warning: Warning :warning:

Make sure that your media_folder points to where your assets or media live. I added an additional uploads folder. I named my public_folder ‘uploads’

  1. Add to github if you haven’t already

  2. Deploy on Netlify

  3. Go into your control panel and and under Identity scroll to the bottom and enable Git Gateway:

  4. setup Netlify Identity

  5. make sure your collections template is filled out in your config.yml file.

  6. Finally, wrap the content you want the CMS to have access to in the following:

import CMS from 'netlify-cms'
// Now the registry is available via the CMS object.
CMS.registerPreviewTemplate('my-template', MyTemplate)

I think that should work for you, but let me know if you have questions.


Hi @Jamie! This is fantastic – huge thank you for taking the time to post. I’m also going to pass this along to our friends at Netlify to see if they’ll help spread the word. 'Cause synergy, right? :laughing:

I image it.

^^ ok, we need to figure out a way to make this a thing. Just great🚀

1 Like

Hey @thedavid I have a PR with Netlify to update their docs:

I think my favorite Redwood :rocket: currently is :hammer: from

:rofl:Ha! That one is legend. Good find. Oh, the good ol’ days.

Scheduled the twitters for tomorrow and sent to Netlify team. We shall see.

Thanks again!

1 Like

I wonder if there’s potential here to just create a NetlifyCMS DB driver that looks at the specified db file much like a SQLite instance. That way, we really don’t need to use slugs or manage the markdown. We talk to the data like we would any other DS in Redwood.

1 Like

Yeah, that would be rad. I feel like the first headless CMS service that finds a way to plug 'n play with Prisma is going to win this game. If I could setup content types on Contentful, then introspect with Prisma, then generate… Well, it would be :exploding_head:

1 Like

Is this a hint on what’s to come? RedwoodJS is probably the piece of underlying software that is best suited to help build that dream headless CMS.

I was vetting a bunch of headless CMS solutions for a client and in the end, I was a bit unhappy with all of them and was tempted to write the CMS experience in a separate app using RedwoodJS-- since the CMS would just be a another client that talks to the same DB/schema as the actual app but w/ a separate set of permissions.

The two main blockers for me in doing that were:

  1. Time
  2. The current inflexibility of RedwoodJS folder structure (I wanted to make a monorepo with all the RedwoodJS /web apps in it sharing the same /api).

There were options such as Git Submodules to share the contents of /api prime. But I just figured this kind of stuff is in the works and given the project cadence, I would not be surprised if the contributors got to this a month or two from now.

I imagine that /api sharing abstraction will eventually turn into the SDK that you distribute to tenants if you were to build this thing in RedwoodJS.


Contentful now supports GraphQL out of the box even on free plans.

If RW could:

  • store the Contentful API content delivery key in an env
  • translate or hand-off queries to another gql server
  • take gql schema and back into a sdl and make services

Then no need for Prisma. For read-only queries.

Here’s some sport teams from one of my Contentful spaces; they offer graphiql too:

1 Like


Is this a hint on what’s to come?

^^ not that I am aware of. But I’m wishing + planting seeds :seedling:

The current inflexibility of RedwoodJS folder structure (I wanted to make a monorepo with all the RedwoodJS /web apps in it sharing the same /api).

^^ Hmm, did you know that a given Redwood Project (i.e. App) can be either a Web side or API side, and doesn’t even require a DB? So one thing you could do is create a project that’s only the API. Then spin it up with yarn rw dev api (note other CLI commands would work similarly like yarn rw build api. Then you could create additional projects that are only the Web side. You’d lose the mono-repo, but gain a singular API. There’d be things to figure out about deployment, but I think it is all possible as is. fwiw



Oh man, there’s something here. This feels like it could open up a whole new world for Redwood.

Contentful now supports GraphQL out of the box even on free plans.

^^ very cool!

If RW could:

  • store the Contentful API content delivery key in an env
  • translate or hand-off queries to another gql server
  • take gql schema and back into a sdl and make services

^^ I didn’t look at Contentful GQL, but would we even need a Redwood API… wouldn’t this make it possible to handle on the front-end using Apollo Client? Any React app could do this, then. I guess I’m just wondering if they are. I still like the concept of having the SDL + Services, but maybe that’s not the next step. :thinking:

Lastly, have you tried any other CMS option, e.g. Sanity or Prismic? I’ve only dabbled in Contentful but I’m seeing the others pop up quite a bit.


Wanted to add what I’ve been experiencing w/ my recent spikes through various headless CMS + RedwoodJS. I’ve been vetting Contentful vs Prismic vs Sanity.

In all three spikes, I just make the headless CMS a service in the /api side much like Prisma DB. I chose not to call the client directly in /web because I like SDL + Services too and that abstraction will eventually allow me to distribute the Headless CMS service wrapper to other targets/clients.

Sanity: I didn’t want to serve my own headless CMS but seems to be most flexible
Prismic: IMO better GraphQL API if you’re gonna use it directly
Contentful: Not so bad if you use the REST API and stitch it into RedwoodJS

IMO both Prismic and Contentful kind of miss the mark in their GraphQL implementations. I think it’s because there is possibly less consideration right now for easy stitching as opposed to just straight consumption. There is a bit of complexity weaving their schema into Redwood. It just seems easier in general to use their REST API and stitch that into Redwood GraphQL instead. But that’s just my opinion and I might just need to learn more about GraphQL.


Yup! I tried going that route. My conclusions:

  • It’s best to have a monorepo for this because you can have unified tests for your deployments much more easily. If the schema changes in /api happen to break anything in other packages/targets, you’d know right away. The tests will be synchronous to the dependency changes which is actually ideal for not shooting yourself in the foot.

  • For the package that contains the main /api, it’s probably best to build a UI around it as a control plane (so it would just be a full rw project). This repo/package would act much like a headless CMS.

  • If I go the multi-repo route for now, I think the best option to share /api would be submodules. I’d also need to trigger tests in all repos against the main /api change.

I ideally wanted something like this:

└── packages
    ├──  api (redwoodjs api)
    ├──  control-plane / handrolled-headless-cms (redwoodjs web)
    ├──  some-other-user-facing-client (redwoodjs web)
    ├──  user-facing-client (redwoodjs web)
    ├──  user-facing-client-ios
    └──  user-facing-client-roku

But the current workspace config gets in the way. It would be amazing, if I was using multiple redwoodjs /web projects in the monorepo and was able to select which project to generate in be like yarn rw user-facing-client g scaffold Resource.

Right now, RedwoodJS’s value for me, by far are the generators and GraphQL/Prisma abstractions. We have to build so little by hand because of those and it just works.


I hope it’s not too much off-topic but I’ve recently been thinking the other way around:

  1. Define your prisma.schema.
  2. Scaffold a RedwoodJS GraphQL API.
  3. Use gatsby-source-graphql.
  4. Static site + Prisma Studio as CMS
  5. ???
  6. Profit
1 Like

Woah! Nice work and thank you for passing along the lessons learned. Especially the evaluations of the CMS providers.

I ideally wanted something like this:

^^ someday we’ll have full support for the concept of Redwood Sides, which means each Yarn Workspace will be a standalone unit that works with CLI and as a monorepo. There’s a POC of a React Native Side, for example. But the tools/config to make Sides possible should allow for what you’re trying to do here.

1 Like

Wait, whaaatttt? I want to see this thing in action.

Also, this really feels like we’re all noodling on something that would be very helpful to a lot of people, including these CMS providers. Gonna :thinking: on it. And not sure the Prisma approach is correct, but I might get their eyes on this as well for some reactions.

1 Like