Deployments

A deployment builds a static site from one commit and publishes the result. A production deployment replaces the live site when it succeeds; a preview deployment gets its own URLs and never touches production. Every deployment has a status, a build log and details.

​

How deployments work

How deployments queue:

• Production deployments run one at a time per site, in the order they were requested, so the most recent one is the one that ends up live.
• Preview deployments build in parallel: previews of different branches run at the same time as each other and as production. Pushes to the same branch still run one after another.
• A site can have 10 deployments queued or running, production and previews together. Beyond that, Deploy now fails with Pending deployment limit reached for static site "<id>", and pushes don’t start a deployment.

A production deployment goes live only when it succeeds: Sevalla switches every domain of the site to it at once and purges the edge cache. Earlier deployments stay in the list. While a deployment runs or waits, a bar at the bottom of every tab of the site shows Deployment in progress (or Deployment queued), with a link to it and Cancel.

​

Deploy by hand

Sevalla deploys the latest commit of the branch. The new deployment shows at the top of the list as Queued or Deploying, then Deployed. Deploy now is also on the Overview tab, under Recent deployments.

​

Deploy automatically on push

With Auto-deploy on, every push to the site’s default branch starts a production deployment. It’s available for sites built from a private repository, and it’s on when you create a site in the dashboard. The Auto-deploy section shows Status Enabled and the Default branch. The default branch is also what Deploy now starts with, and the branch previews leave out.

​

Choose which changes deploy

Deploy paths decide whether a push starts an automatic deployment (production or preview), based on the files the push changed. They don’t affect Deploy now. A push they exclude still shows in the list, with the status Skipped. Patterns use glob syntax and are relative to the repository root: * matches within a folder, ** across folders. For example, apps/docs/** matches every file under apps/docs, and **/*.md matches Markdown files in any folder. Don’t start a pattern with /: changed files are compared without one, so /apps/docs/** never matches. Deploy paths need the list of files a push changed, which GitHub and GitLab send. Bitbucket pushes don’t include the list of changed files, so deploy paths can’t filter them: every push to a static site built from a Bitbucket repository deploys, whatever its deploy paths. The Deploy paths section shows the mode and lists the patterns. Each pattern is required and can appear only once (Path is required, This path is already in the list).

​

Pull request previews

Pull request previews build every push to a branch other than the default branch and publish it on its own URLs, so you can review a change before you merge it. They’re available for sites built from a private repository, and they’re off for new sites.

​

Enable pull request previews

The Pull request previews section shows Status Enabled. The Deployments list gets an Environment column with Production or Preview, and environment variables get a choice of Production and Preview. To turn previews off, click Disable previews, then Disable previews in the dialog. Previews that already exist keep working until Sevalla deletes them.

​

How previews work

• Every push to another branch starts a preview, whether or not the branch has an open pull request. Deploy paths apply. On GitHub, pushing a new branch with no new commits doesn’t start one.
• Each successful preview has two URLs on the site’s sevalla.page domain:

  URL	Format	Shows
  Branch preview	<name>-branch-<branch>.sevalla.page	The branch’s latest successful preview
  Commit preview	<name>-commit-<commit>.sevalla.page	That commit, for as long as the preview exists

  <name> is the site’s name, <commit> the first 7 characters of the commit SHA, and <branch> the first 22 characters of the branch name with every run of characters other than letters and digits replaced by -. For example, a push of commit 5c7e9a1 to feature/search on the site acme-shop-k3x9p publishes acme-shop-k3x9p-branch-feature-search.sevalla.page and acme-shop-k3x9p-commit-5c7e9a1.sevalla.page.
• Sevalla comments on the pull request. For each open pull request from the branch, Sevalla posts a comment titled Preview deployments for <display name>, with the status and links to both previews, and updates it on every push. On GitHub, it also reports a deployment in the preview environment that links to the commit preview.
• Previews build with the variables marked Preview. A variable the API limits to one branch is used only in that branch’s previews. See Environment variables.
• Previews apply your _redirects and _headers files, but not pretty URLs.
• Previews never change the site’s status: a failed or running preview doesn’t mark the site as failed or block updates to it.
• Previews count toward the company’s free build minutes and bandwidth, like production. See Pricing and free allowances.
• Sevalla deletes a preview 30 days after it finishes. Its files and URLs go away; the deployment stays in the list. A branch preview URL lasts 30 days after the branch’s latest preview.

​

Open a preview

​

Follow a deployment

Click a deployment on the Deployments tab, or under Recent deployments on the Overview tab. Its page has three parts:

• The header: the status, Production or Preview, the repository and the branch, and Visit site (production) or View previews (preview).
• Deployment logs: the build log with the time the deployment took. It streams live while the deployment runs. Turn on Wrap for long lines and UTC for UTC times. The menu at the top right of the log has Refresh, Copy all lines, Download as JSON and Download as CSV. The browser tab’s icon shows the deployment’s status.
• Details: Deployed branch, Commit (linked to your Git provider), By (the commit’s author), Trigger (with the person’s name for a manual deployment), Started at and Commit message.

The Deployments list shows, for each deployment, the commit message, status, author, commit and branch under Source, the Environment (with previews on), the Trigger, and Date · duration. Choose 10 to 50 rows per page. If a deployment fails, its log shows the step that failed. See Troubleshoot static sites for common errors.

​

Cancel a deployment

The bar cancels the running deployment, or the queued one if none is running. A running deployment becomes Cancelled; a queued one becomes Skipped. The site keeps serving its current version. To cancel a specific deployment, use the API or the CLI. A deployment that has finished can’t be cancelled: Deployment "<id>" cannot be cancelled because it has status "<status>".

​

Git LFS

With Git Large File Storage (LFS) on, Sevalla downloads the files your repository tracks with Git LFS when it clones it, so the build gets their content. With it off, LFS-tracked files are checked out as small text pointers. It’s on for new sites, for private and public repositories. The section’s Status shows Enabled or Disabled. The change applies from the next deployment.

​

Git submodules

Sevalla clones Git submodules with the repository. A private submodule must be on the same Git provider as the site’s repository and readable with the same access; a site built from a public repository can use public submodules only. See Git submodules.

​

API and CLI