Product

Deployments

A Stackap deployment turns a git push into a running, HTTPS-served app: the server builds an image, starts it beside the old version, checks that it is healthy, and only then switches traffic.

What it does

You push your code to your project's git remote on the Stackap server over SSH, or run stackap deploy <slug>, which pushes your current HEAD for you. Only pushes to the project's production branch start a build. Pushes to other branches are stored and ignored.

If the repository has a Dockerfile, Stackap builds it. If it has none, Stackap generates one for the project types it recognizes: Next.js, single-page apps built with Vite, Create React App, Vue CLI or Parcel, static-output sites (Astro, Docusaurus, Gatsby, Eleventy, VitePress), a plain index.html, and Node apps with a start script. The frameworks section lists exactly what is recognized. A project Stackap cannot classify fails with a stated reason, and whatever was live keeps serving.

Build-time secrets are handled deliberately. Variables beginning with NEXT_PUBLIC_ are passed through, because they are public by design. Every other variable is replaced with a placeholder while the image builds, so a secret is never baked into an image layer. Real values reach the container only when it runs, through a private file and not on a command line.

How it works

1. Push. The push arrives at a restricted SSH user that can only send and receive git repositories.
2. Queue. A hook tells the control plane over a localhost-only, secret-protected endpoint. The push is recorded and a build is queued.
3. Build. Docker builds the image on the same machine. A 31,592-page Next.js site builds there in about 96 seconds, peaking near 2.8 GB of the server's 7.75 GB of memory.
4. Health check. The new container starts next to the old one and is polled until it answers successfully or a timeout expires. A container that crashes, hangs or errors is discarded, and no visitor was ever sent to it.
5. Swap. Only after the check passes does Stackap change the routing table, inside a database transaction, so the change happens completely or not at all. Caddy then sends traffic to the new container.

Each project also has a port and a health-check path. They default sensibly and can be set per project by the owner (PUT /v1/projects/:slug/settings). An API-only app that does not answer on the default path needs its own; that case has been tested with a toy app on port 8080 and /healthz.

In practice

$ stackap deploy my-app
$ stackap deployments my-app
$ stackap logs my-app --source build
$ stackap logs my-app --source runtime --limit 100

Early-access scope

• No preview deployments. A branch other than production is stored but never built, so there is no per-branch preview URL.
• No built-in test gate. Whatever builds and passes the health check on the production branch goes live, so run your tests before you push.
• Builds run on the same machine as your live apps. A heavy build competes with them for memory and CPU. The 96-second build above did not disturb the other sites, but it is one measurement, not a guarantee.
• Stackap does not watch GitHub or any other host. You add the project's Stackap git remote next to your existing one and push to it.
• A repository with no Dockerfile that is not one of the recognized types is refused rather than guessed at.

Questions

Last updated 2026-10-03.