Frameworks

Astro on Stackap

Stackap builds a static Astro site in a container and serves the output from nginx with genuine 404 responses; an Astro project that uses a server adapter is deliberately not treated as static.

How Stackap recognizes Astro

A project is treated as a static site when it has a build script, lists astro as a dependency, and does not list a server adapter. The adapters that disqualify it from the static path are @astrojs/node, @astrojs/vercel and @astrojs/netlify, because those produce server code, not files. The same static path serves Docusaurus, Gatsby, Eleventy and VitePress.

What Stackap builds

The image builds your site with the package manager the lockfile implies and copies the output into nginx. Unlike the single-page-app path, unknown URLs return a real 404 page, which is what a content site wants for search engines.

Because nothing runs on the server, there is nothing to start, nothing to crash and almost no memory use. It is the cheapest kind of app to host on one box.

What a Astro project needs

• Astro configured for static output, which is its default.
• A build script that writes the finished site.
• No server adapter in the dependencies. If you have one only for local development, remove it for the production build.
• A 404.html or 404 page if you want a custom not-found screen.

Verification status

The static-site path is covered by a real Docker build in the platform's test suite. This site, www.stackap.com, is itself a static site served by a similar nginx container, built from its own Dockerfile, though it is generated by a Python script and not by Astro.

Still to verify: an Astro project built end to end by us. We have not shipped an Astro site on Stackap, so treat Astro-specific behavior, such as content collections or image optimization at build time, as unverified. An Astro project with a server adapter is either treated as a Node app, if it has a start script, or refused with an explanation.

Early-access scope

• No Astro site has been deployed on Stackap by its builders yet, so the support rests on the generic static-site path and its tests.
• Server-side rendering and on-demand routes are not supported through the static path.
• Image optimization that runs at request time on another platform has no equivalent here; build-time optimization works because it produces files.
• No CDN, so the same latency caveat as every other Stackap site applies.

Questions

Last updated 2026-10-03.