Publishing projects from Plasmic Studio

You can publish your changes directly from Plasmic Studio, using the Publish button in the toolbar. Included is the ability to deploy changes to production. This empowers Plasmic Studio users, including non-developers, to freely iterate on their designs and content, without involving developers.

Publishing enables any of the following:

  • Versioning: Simply save versions of your project. You can see historical versions and restore them any time.
  • Cross-project imports: Publish a version of your project for other projects to import. For instance, publish a central design system that multiple downstream projects can depend on. Learn more.
  • Call webhooks: If you have a custom build pipeline—for instance, one running on Jenkins, Netlify, Vercel, GitHub Actions, or elsewhere—you can kick off jobs using webhook integrations. This is useful if you are using the Headless API or (for Codegen) have plasmic sync running as part of your CI/CD process.
  • Versioned code sync: Ensure that developers will sync only published versions into the codebase and not any work-in-progress changes you may have in flight. You can further limit syncing to accept only backward-compatible changes. Learn more.
  • Push to GitHub: Push commits or PRs to any GitHub repo, or trigger PlasmicLoader builds (run by GitHub Actions). You can create a brand-new repo from scratch, which lets you choose a React stack. But this also works for existing repos that do not already have Plasmic installed, where we’ll inspect your codebase to auto-detect the right options to configure Plasmic with.
  • Publish a website: When creating a new GitHub repo, you have the option to publish a full website end-to-end. This is powered by the GitHub Pages CDN, but lets you choose a domain (which you can later change to any custom domain). This lets you instantly deploy without touching any code or CLI. And since this is just using your GitHub repo, you can at any time start adding arbitrary React code! (The repo includes a GitHub Actions workflow that will automatically build and deploy when you push commits to the main branch.)

Continuous deployment with webhooks

Most continuous deployment platforms provide webhooks for triggering builds and deploys (e.g. Vercel, Netlify, AWS Amplify, Jenkins). If you are using any of them all you need to do is to make sure your build command is picking up changes in your Plasmic project, then add the webhook to your Plasmic project publish settings.

After you have integrated Plasmic into your codebase, add a custom webhook to your Plasmic project by opening the project in Plasmic Studio, clicking on the Publish button, expanding “Custom webhooks” section, and clicking on “New webhook”.

You can add multiple webhooks and, for each of them, specify a method, a URL, custom headers and payload.

Publishing custom webhooks

All Plasmic users with editor access to the project can then hit “Publish” again to trigger the existing webhooks.

Viewing version history

All project versions will show up on the “Published versions” panel on the left in reverse chronological order.

You can view any project version by clicking on the entry. This will load a read-only snapshot of the project from that moment in time.

  • Changes in read-only mode will not be saved
  • You can return to edit mode either by clicking on the action button in the alert banner or reloading the studio

Hosting options

Plasmic does not provide website hosting. It lets you host anywhere, and there exist many great free hosting providers.

You can deploy your website end-to-end in a matter of clicks straight from Plasmic Studio. This is powered by GitHub Pages, and includes your choice of a free domain. The build and deploy pipeline is run using GitHub Actions.

Additionally, since Plasmic integrates with code, it is easy to deploy your site with other great hosting providers such as Vercel or Netlify. These dedicated providers provide many benefits—for instance, Vercel’s GitHub integration automatically publishes staging previews for each pull request, so you can see what the website will look like.

Getting started with either provider is easy:

Beyond these providers, you can take your Plasmic project anywhere—from major cloud platforms like AWS Amplify and Google Cloud Firebase, to VPS providers like Linode and Digital Ocean.

Changing your domain on GitHub Pages

When using the out-of-the-box GitHub Pages-powered hosting, you can easily change your domain to any other \* domain (as long as it’s not already taken) or to any custom domain you have.

To do so, browse to your repo on, go to the Settings tab, and simply change the domain in the GitHub Pages settings:

GitHub Pages settings

To use a custom domain:

  1. Purchase one from any provider such as Namecheap or Google Domains, or obtain a free one from a provider such as

  2. Configure your DNS provider with the appropriate A and CNAME records as described in the GitHub docs.

Publish to the Plasmic Showcase!

No matter where you take your project, we love to hear about where your site ends up!

We will be putting together a gallery of websites and apps that users have made with Plasmic. You can help the Plasmic community grow by inspiring others with your own example of what can be built with Plasmic, and at the same time give your site some extra visibility!

Let us know what you’re working on in the Slack Community or at

Deploy to a staging environment

When you hit Publish, it typically (1) saves a new version and (2) triggers a production build/deploy. Instead, you can setup your code + CD pipeline to support a staging environment.

First, do the following one-time setup:

  1. In your code, make the staging build render the preview of the Plasmic design. For instance, if you use an environment variable DEPLOY_ENVIRONMENT=staging:

    const PLASMIC = initPlasmicLoader({
    projects: [
    preview: process.env.DEPLOY_ENVIRONMENT === 'staging'
  2. Make sure your CI/CD pipeline for the staging build is appropriately setting the needed environment variables (such as DEPLOY_ENVIRONMENT in the example above).

  3. Add a second webhook to trigger the CI/CD pipeline that publishes to staging. This should be similar to the one you set up for production, so now you have two webhooks configured.

From now on, editors can trigger a staging deployment when they click the Publish button:

  1. Uncheck the “Save a version” checkbox. This prevents any subsequent production builds from accidentally consuming these latest changes.

  2. Check just the webhook for publishing to staging.

Give feedback on this page