Frameworks

Gatsby on Stackap

Stackap builds a Gatsby site with its build script, finds the finished pages in the public folder, and serves them from nginx with real 404 responses.

How Stackap recognizes Gatsby

A project is a Gatsby site when it has a build script, lists gatsby as a dependency, and has no server-rendering dependency from the excluded list. It then takes the static-site path, shared with Astro, Docusaurus, Eleventy and VitePress, which gives real 404s instead of the single-page-app fallback.

What Stackap builds

Gatsby writes its output to public. That folder is on the list Stackap searches, in an order that checks dist, build and out first, so a project that happens to have an index.html in one of those earlier folders would be served from there instead. A normal Gatsby project does not.

The nginx stage caches scripts, styles, fonts and images for a day, and anything under /assets/ for a year, so a project that puts files under that path should give them hashed names.

Image processing, which Gatsby does at build time, runs inside the build container. It is the heavy part of a large Gatsby build and uses memory the live apps also need.

What a Gatsby project needs

• A build script, normally gatsby build.
• Static output only: no server-side rendering or deferred static generation that needs a server at request time.
• A lockfile.
• Enough build memory for your image count.

Verification status

The static-site path is covered by a real Docker build in the platform's own tests.

Still to verify: a Gatsby project built by us. Gatsby-specific behavior, such as large image pipelines or plugins that call external services at build time, is unverified.

Early-access scope

• No Gatsby site has been shipped on Stackap yet.
• Gatsby features that render on a server at request time are not served by this path.
• Builds share the machine with live apps, so a very large site build can slow them for its duration.
• No CDN in front of the files.

Questions

Last updated 2026-10-03.