How to deploy Gatsby with Strapi on Platform.sh

Platform.sh maintains a template that you can quickly deploy, and then use this guide as a reference for the Platform.sh specific changes that have been made to Gatsby and Strapi to make it work. Click the button below to sign up for a free trial account and deploy the project.

Shared configuration

Your local clone of the template has the following project structure:

├── .platform
│   ├── routes.yaml
│   └── services.yaml
├── strapi
│   ├── # App code
│   └── .platform.app.yaml
├── gatsby
│   ├── # App code
│   └── .platform.app.yaml
└── README.md

From this repository, you deploy a Gatsby app and a Strapi app. The code for each of them resides in their own directories. When deploying a single app project such as Gatsby, the repository needs three configuration files that describe its infrastructure, described below in detail. For multi-app projects, two of those files remain in the project root and are shared between Gatsby and Strapi. Each app keeps its own app configuration file (.platform.app.yaml) in its subdirectory.

Service configuration

This file describes which service containers (such as a database) your project should include. Gatsby does not require services to deploy, but Strapi does. So the following examples shows these service configurations:

# The services of the project.
#
# Each service listed will be deployed
# to power your Platform.sh project.

dbpostgres:
    type: postgresql:12
    disk: 256

Routes configuration

This .platform/routes.yaml file defines how requests are handled by Platform.sh. The following example shows Gatsby being served from the primary domain and Strapi being accessible from the backend subdomain.

# The routes of the project.
#
# Each route describes how an incoming URL is going
# to be processed by Platform.sh.

"https://www.{default}/":
    type: upstream
    upstream: "gatsby:http"

"https://{default}/":
    type: redirect
    to: "https://www.{default}/"

"https://www.backend.{default}/":
    type: upstream
    upstream: "strapi:http"

"https://backend.{default}/":
    type: redirect
    id: 'strapi'
    to: "https://www.backend.{default}/"

Strapi

The multi-app template has a single modification to Platform.sh’s standard Strapi template: the name attribute in Strapi’s .platform/services.yaml has been updated to strapi. This value is used to define the relationship between Gatsby and Strapi and in the routes configuration.

The only additional setup required to prepare the backend is to install a package that will enable GraphQL on Strapi. In your Strapi directory, add the dependency:

yarn add strapi-plugin-graphql

Gatsby

The frontend Gatsby app has a slightly different configuration from the basic Gatsby deployment. Below is the gatsby/.platform.app.yaml file that configures the app.

# .platform.app.yaml

# The name of this application, which must be unique within a project.
name: gatsby

# The type key specifies the language and version for your application.
type: 'nodejs:14'

# The hooks that will be triggered when the package is deployed.
hooks:
    # Build hooks can modify the application files on disk but not access any services like databases.
    post_deploy: |
      npm run build      
# The size of the persistent disk of the application (in MB).
disk: 1024

relationships:
   strapi: "strapi:http"

# The configuration of the application when it is exposed to the web.
web:
    locations:
        '/':
            # The public directory of the application relative to its root.
            root: 'public'
            index: ['index.html']
            scripts: false
            allow: true

mounts:
  '/.cache':
      source: local
      source_path: cache
  '/.config':
      source: local
      source_path: config
  'public':
      source: local
      source_path: public

In particular, notice:

• relationships

  Access to another service or app container in the cluster is given through relationships. In this case, one has been defined to the backend Strapi container using it’s name.

• post_deploy

  Platform.sh containers reside in separate build containers at build time, before their images are moved to the final app container at deploy time. These build containers are isolated and so Gatsby can’t access Strapi during the build hook, where you would normally run the gatsby build command. Strapi isn’t available until after the deploy hook. So the Gatsby build is postponed until the post_deploy hook.

  To run gatsby build on-demand, or to trigger a rebuild from the backend when content is updated, define a runtime operation.

• mounts

  There are consequences to postponing the Gatsby build, as you don’t generally have write access to the container this late in the pipeline. To allow Gatsby to write to public, that directory has been defined as a mount.

You can then modify gatsby-config.js to read from the backend Strapi container through the strapi relationship defined above to configure the apiURL attribute for gatsby-source-strapi. Note that the source plugin requires that you explicitly define the contentTypes to retrieve from Strapi. At this point, you haven’t yet built out the API. So the article and category content types are included for what you need to do after installing. If you’re migrating an existing Strapi repository, adjust these values to fit your current API.

This is facilitated by Platform.sh’s Config Reader library. So be sure to install this to the Gatsby dependencies first when replicating. When used, Gatsby pulls the information to communicate with the Strapi container on the current branch.

const config = require("platformsh-config").config();

var backend_route = "";
if ( config.isValidPlatform() ) {
  require("dotenv").config({
    path: `.env.${process.env.NODE_ENV}`,
  })
  backend_route = `http://${config.credentials("strapi")["host"]}`
} else {
  require("dotenv").config()
  backend_route = process.env.API_URL;
}


module.exports = {
  siteMetadata: {
    title: "My super blog",
    description: "Gatsby blog with Strapi",
    author: "Strapi team",
  },
  plugins: [
    "gatsby-plugin-react-helmet",
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        name: `images`,
        path: `${__dirname}/src/images`,
      },
    },
    {
      resolve: "gatsby-source-strapi",
      options: {
        apiURL: backend_route,
        contentTypes: [
          // List of the Content Types you want to be able to request from Gatsby.
          "article",
          "category",
        ],
        queryLimit: 1000,
      },
    },
    "gatsby-transformer-sharp",
    "gatsby-plugin-sharp",
    {
      resolve: `gatsby-plugin-manifest`,
      options: {
        name: "gatsby-starter-default",
        short_name: "starter",
        start_url: "/",
        background_color: "#663399",
        theme_color: "#663399",
        display: "minimal-ui",
      },
    },
    "gatsby-plugin-offline",
  ],
}

Lastly, the Gatsby app itself needs to include GraphQL queries to handle the data coming from Strapi and create content pages. The most important files in the template you should consult are:

• gatsby/gatsby-node.js

  Dynamically creates individual pages from the data source using Gatsby’s Node API. It retrieves all of Strapi’s articles and categories (see post-install below) using the GraphQL queries allStrapiArticle and allStrapiCategory respectively. For each, a page is created (createPage) with an assigned path and formatting described by one of the template files below (component).

• gatsby/src/templates/article.js

  The template file that defines how a single Strapi article should be formatted on Gatsby, retrieving the data from that article using the strapiArticle GraphQL query.

• gatsby/src/templates/category.js

  The template file that defines how a list of articles that belong to a single Category are formatted by Gatsby. It uses the Category query, and then filters a specific category id on allStrapiArticle.

• gatsby/src/pages/index.js

  Retrieves all of Strapi’s content to generate a list of articles on the homepage using the allStrapiArticle GraphQL query.

Deploy and post-install

Next steps

With Gatsby now deployed and pulling content from a backend Strapi application, there are a few things you may wish to change about your project going forward.

Shared application configuration

You can optionally combine the application configuration (.platform/services.yaml) for Gatsby and Strapi into a single configuration file. Like .platform/services.yaml and .platform/routes.yaml, this file is shared across the project and resides in the .platform subdirectory. You need to explicitly define the source of each application.

Multiple content sources

Gatsby supports pulling multiple sources into its build. This includes external services like Stripe and additional backend CMSs for different sets of content. As in this example with Strapi, you can branch off your repository and add an additional directory that contains the codebase for another backend. Then add the source plugin for that backend to gatsby-config.js.

Plan size

As mentioned previously, you should have at least a Medium plan for your multi-app projects. This size gives the project enough resources for all of your containers as well as the memory necessary to actually pull content from Strapi into Gatsby during its build.

Keep in mind that the increased plan size applies only to your production environment, and not to preview environments (which default to Standard ). As you continue to work with Gatsby and a backend headless CMS, you may want to upsize your preview environments.