Skip to content
Stackship documentation Svenska

Static Web AppsUsers

Static Web Apps

Serve a directory of a Git repository over HTTPS exactly as it is committed, with no build step and no server code.

A static web app serves one directory of a Git repository over HTTPS, file for file, exactly as it is committed. Nothing is built and none of your code runs on the server: the platform copies the files into a web server image and serves them. What you configure is where the files come from, how requests are routed and cached, and which address the site answers on.

Static web app or app?

  • Use a static web app when the repository already holds the finished site: HTML, CSS, JavaScript and images, written by hand or produced by a build whose output you commit.
  • Use an app when the site has to be built first — React, Vue, Astro, Next.js, Hugo, anything with a build command — or when it needs server code, settings or secrets while it runs. See Apps.

A static web app has no build settings, no environment variables and no secret references: there is no build to pass them to and no process to read them.

What a deployment does

Every deployment packages the site again:

  1. The platform clones the repository at the site's branch — at the commit of the last push it received for that branch, or at the head of the branch when it has received none — and takes the Directory to serve from it.
  2. It checks the directory. The deployment fails when the directory does not exist, is empty, has no index.html, or holds a package.json with a build script — the sign of a site that needs a build.
  3. It removes repository and tooling files from the top level of the directory: .git, .github, .gitlab, .gitlab-ci.yml, .stackship, node_modules, package.json, lock files (package-lock.json, *-lock.yaml, *.lock, *.lockb), tsconfig.json and jsconfig.json, and files whose names begin with .env in the top two levels. Copies deeper in the directory, such as a node_modules folder in a subfolder, are packaged and served like any other file; only names that begin with a dot are always refused — see Other rules.
  4. It builds an image from what is left, stores it in the platform's container registry and rolls it out.

The site keeps serving its previous deployment until the new one is ready. A deployment that fails leaves the previous one serving; the site then shows Degraded, or Error when nothing served before, until a later deployment succeeds.

Note

A deployment whose packaging fails is started again automatically. About five minutes after the failure the platform packages the same source again, as a new deployment, and it goes on doing so until a deployment succeeds: each attempt adds another Failed row to the Deployments tab. Fix the cause — push the fix, or change the site's source or directory — to end it.

A site deploys when it is created, when you choose Deploy or restart it with the CLI or API, when you change its source or its directory, and on every push to its branch — see Automatic deployments.

Routing without a redeploy

The single-page app fallback, the 404 page and the cache preset are not part of the image. The platform turns them into the web server's configuration, so a change takes effect within seconds and the site is not packaged again. What each setting does, and the exact cache headers, are in Routing and caching.

Address and certificate

Every site gets a platform address under apps.example.com, built from the boundary, the resource group and the site name; the create wizard shows it before the site exists. You can add a custom domain, and the platform address keeps working next to it.

A site is always served over HTTPS with a certificate from Let's Encrypt, and plain HTTP is redirected to HTTPS. There is no HTTP-only mode.

Pages