PlasmicLoader vs. Codegen

Turning your designs into production code is Plasmic’s flagship capability. Plasmic has two methods of consuming designs built in Plasmic from your codebase. We’ll look at each and then help you decide which makes sense.


You use the Plasmic CLI (plasmic sync) to pull Plasmic-generated React code directly into your git repo. You treat the generated code just like any React code—it is checked into your git repo, versioned with git history, and deployed by your usual pipelines. As “just code”, you can review, test, deploy, and rollback design changes just as you can any code changes.

However, that means whenever you want to deploy some design changes to production, you’ll need to run plasmic sync to generate new code, create a git commit, possibly go through code reviews, merge the commit into main branch, and deploy as usual. Because the Plasmic-generated code lives in your codebase, deploying changes necessarily involves developers who have access to work through this workflow. Depending on your use case, this may be fine, or too heavyweight.


(Currently for Next.js/Gatsby only.)

No Plasmic-generated code is checked into your git repo.

Developers need only insert a one-time plugin snippet into their Next.js/Gatsby config, specifying a Plasmic project ID, such as:

// Example for next.config.js.
const withPlasmic = require('@plasmicapp/loader/next')({
  projects: ['PROJECT_ID']

From there on out, the latest pages will be fetched from the Plasmic project as part of the Next.js/Gatsby site’s build process, served at the specified routes.

Or, if you want to render a non-page component somewhere in your app, you use a PlasmicLoader component:

<PlasmicLoader component="LandingPagePromotion" />

Thereafter, PlasmicLoader will always fetch the latest pages from Plasmic when you build the Next.js/Gatsby site.

That means whenever you want to deploy some new or updated pages/components to production, you just need to trigger a re-build of the Next.js/Gatsby site, which will pick up the latest changes, without involving developers.

If you are familiar with Content Management Systems, this is a very similar workflow—once the build-time fetching is integrated into the codebase, non-technical content owners in the marketing and design teams can exercise autonomy in publishing content without blocking on developers.

Which scheme should you use?

In short, PlasmicLoader makes it possible for non-developers to push design changes without ongoing developer involvement. We believe it is a great workflow for projects involving mostly static designs, where designers / marketing / etc. want to be able to deploy changes made in Plasmic without involving developers. These are similar workflow benefits to adopting a CMS—PlasmicLoader lets you use Plasmic as a CMS that gives you full visual control and page-building capability.

You should consider using PlasmicLoader if you:

  • Are building mostly-static designs that don’t require heavy code instrumentation (websites, most JAMstack projects, promotional banners, etc.)
  • Want to make design changes in Plasmic without going through the typical code commit workflow, so that non-developers can easily get their changes deployed without involving developers
  • Prefer not having Plasmic-generated code be in your codebase and git history

You should still use codegen if you:

  • Are building a dynamic app with a lot of code instrumentation (via overrides passed to Plasmic* components)
  • Want generated Plasmic* files to be checked into your git repo, as part of your git history
  • Don’t mind having to go through the typically developer-owned workflow of running plasmic sync, creating a git commit, merging into main, etc. when you make design changes in Plasmic
  • Are not using Next.js/Gatsby