Category: 12. Deploying Gatsby

Once you’ve configured your deployment, whether that means populating environment variables or customizing path and asset prefixes, it’s time to deploy your Gatsby site to an infrastructure provider. There are a variety of hosting solutions for Gatsby sites that run the gamut from static site hosting companies such as Netlify, Vercel, and Gatsby Cloud to broader hosting platforms that offer…

The end result of a Gatsby build is a collection of HTML files representing the Gatsby site and assets such as images, videos, JavaScript files, and CSS files. Today, it’s common practice for Gatsby developers to deploy the Gatsby-generated static HTML to a domain root but to leverage a different domain, such as a CDN, for…

Sometimes, Gatsby developers need to implement sites that fit into an existing path system on a domain that houses other sites. For instance, you may have a Gatsby site that coexists with other Gatsby sites and needs to be under a particular path (say, example.com/gatsby-site). As a matter of fact, some hosting providers—notably GitHub Pages—obligate the use…

The vast majority of Gatsby sites are hosted at the root of their domain (e.g., example.com/), and their assets are usually located in some directory within that domain (e.g., example.com/img or example.com/css). However, there are certain scenarios in which Gatsby developers prefer to host their Gatsby sites at a different location than the domain root, as well as situations…

It’s a best practice not to commit environment configuration files to source control providers unless there is absolute certainty no sensitive credentials are contained inside. Many Gatsby developers utilize local environment configuration files to manage that sensitive information outside of source control, while simultaneously providing environment variables to continuous deployment (CD) providers in the infrastructure provider’s…

Unlike other implementations that leverage universal JavaScript, Gatsby performs all compilation at build time, which means that only those scripts executed during the build will provide environment variables on the server side. More specifically, Gatsby runs a few Node.js scripts in succession during the build-time compilation process, including the logic found in gatsby-config.js and gatsby-node.js. Because Node.js has access to…

With regard to environment variables that need to be available in the client-side JavaScript bundle generated by Gatsby, it’s a best practice to create an environment configuration file, which carries the prefix .env and usually an extension that identifies the environment in question. For a development environment, this takes the form .env.development, whereas for a production environment, the form is .env.production.…

Environment variables in Gatsby can be placed: In client-side JavaScript through environment configuration files, as we’ve seen in previous sections In server-side Node.js implementations via infrastructure providers like Netlify, operating systems, or command-line executions of NPM scripts Let’s take a closer look at client-side environment variables and server-side environment variables in turn.

Gatsby developers can use environment variables to provide values that need to be distinct across development environments. They are most commonly used to obfuscate certain information that may be sensitive and should not be exposed to others. Some environments require different information to customize behavior in those environments. Others, for security reasons, need to ensure certain…

Once you’ve done the work to spruce up your codebase (through best practices for testing and debugging your Gatsby site), it’s time to push your site into production so your users can begin to interact with your Gatsby implementation. Because it’s an SSG at its core, there are several aspects of Gatsby that require some…