Git builds for static sites, in Paris

Connect GitHub, GitLab, Codeberg, Forgejo or Bitbucket. Every push builds in a fresh, isolated container in Paris, and your default branch goes live when the build passes. A failed build never touches production.

A real build of a blog project from its main branch: clone 1.1 seconds, build 28.6 seconds, upload 5.5 seconds, live in 40 seconds, with lines from its build log.

Your Git host, not ours.

Your code stays where it is. Connect a repository and every push builds: your default branch goes live, every other branch gets its own preview address.

GitHub, GitLab, Bitbucket, Codeberg and Forgejo all feed the same build. A push to a blog repository on Codeberg builds in 40 seconds; its main branch goes to production and every other branch to a preview address.

One commit, one build

If your Git host sends the same push twice, it still builds once. Every delivery is checked against its secret before anything runs.

Self-hosted Forgejo too

Point a project at your own Forgejo or Gitea. From Forgejo 16 we can clone with a short-lived token per build instead of storing yours.

Your framework's defaults, already filled in.

Pick a framework and the build command and output folder are set for you. Change either one; any single-line shell command works.

Default build command and output folder per framework
FrameworkBuild commandOutput folder
Astronpm run builddist
SvelteKitnpm run buildbuild
Next.jsnpm run buildout
Vitenpm run builddist
Gatsbynpm run buildpublic
Hugohugo --minifypublic
Jekyllbundle exec jekyll build_site
Static HTMLnone.

Your package manager, from the lockfile

npm, pnpm and Yarn install exactly what your lockfile says. Picking a repository through our GitHub app fills in the framework and package manager for you.

npm ci --ignore-scripts
pnpm install --frozen-lockfile --ignore-scripts
yarn install --frozen-lockfile --ignore-scripts

Install scripts do not run

A dependency cannot run code while it installs, which closes a common supply-chain attack. Your own build command runs as usual.

A package that needs its install script, such as a native module, can fail here.

A sealed room for every build.

Each build gets its own container in Paris, starts from an empty disk and is deleted when it ends. Nothing carries over from the last build, and nothing reaches the next one.

What every build container gets
CPU0.5 guaranteed, up to 1.5
Memory2.5 GiB guaranteed, up to 4 GiB
Disk10 GiB, empty at the start
Time10 minutes
Runs asuid 1000, every capability dropped
Networkout on ports 80 and 443, private ranges blocked

Secrets only while it runs

Environment variables are stored encrypted, scoped to production, previews or both, and handed to a build for its lifetime only. Your Git token never reaches your build command.

Minutes only when it works

A failed or timed-out build costs no build minutes. You pay for the builds that ship.

When a build fails, it says why.

The log ends with a summary: the stage that failed, what happened and what to change. Production keeps serving the last deployment that worked.

The end of a real failed build log from the same project: the build exceeded the ten minute time limit.

Named, not just failed

A wrong output folder, a missing program, a clone that was refused, memory running out: each gets its own sentence. A wrong output folder names the folders your build did write.

An email, not a flood

A failed push build emails your team, at most once per project every six hours. A deploy you started yourself emails you.

What builds do not do yet.

  • A build cache Every build installs its dependencies from scratch.
  • Choosing a Node version Node builds run on Node 24. .nvmrc and engines are not read.
  • Your own build image Images are set per framework. There are no Dockerfile builds.
  • Git submodules The clone does not fetch them.
  • Skipping a build No [skip ci] keyword, and no filter by changed paths in a monorepo.
  • Build results on your pull request GitHub and Bitbucket get a pending status only; no success, failure or preview link yet.

Questions about builds.

Something else? Write to support@deploybase.eu. A person answers.

Which Git hosts can deploybase build from?

GitHub, GitLab, Bitbucket, Codeberg, and self-hosted Forgejo or Gitea. On GitHub you can install our app or use a per-repository webhook; on the others we register the webhook for you. Pushes and pull or merge requests both start builds.

How builds work
How many build minutes do I get?

200 a month on Free, 1,000 on Starter, 3,000 on Pro and 10,000 on Scale. Only builds that succeed count: a failed or timed-out build costs nothing. Pro and Scale also queue ahead of the others when the build machines are busy.

Plan limits
How long can a build run?

Ten minutes, with up to 4 GiB of memory and 1.5 CPUs. A build that needs more fails with a timeout or out-of-memory message that says so. Write to support if your build genuinely needs more.

Is there a build cache?

No. Every build starts from an empty disk and installs its dependencies again. That costs some seconds and means nothing from an earlier build, or another customer's, can leak into yours.

Can I deploy without Git?

Yes. Upload a built folder from the dashboard or the command-line tool, up to 250 MiB on Free and 1 GiB on paid plans. An upload goes straight to production without a build.

Does it work with a monorepo?

Set the project's root directory and the build runs there, so one repository can hold several sites. Every push to the repository still builds; filtering by changed paths is not built yet.

Connect a repository and push.

Create a team on the free plan, connect a repository, and your next push builds in Paris.