All documentation
Getting started

Create a site

A site binds a domain to a repository and a runtime on one of your servers.

What you provide

Choose New site from the + menu in the sidebar, from ⌘K, or from a server’s Sites view. The form asks for:

  • Server. Any active server in the team.
  • Domain. The primary hostname, plus up to 10 aliases. Aliases are included on the site's first certificate.
  • Repository and branch. Pick one through the GitHub App, or paste any Git URL. A site created from a Git URL gets its own deploy keypair. Its Settings show the public half under Source, for you to add as a deploy key at your Git host.
  • Runtime and version. See Runtimes.
  • Subdirectory. Optional, for a monorepo.

A site on a GitHub App repository deploys as soon as it is created. A site from a Git URL waits for you, so you can add its deploy key at your Git host and fill in the environment file before anything is built. Its Overview shows the key until the first deploy.

Directory layout

/home/provisore/sites/api.example.com/
  releases/20260711091403-a1b2c3d4/   # each deploy builds here
  current -> releases/…               # atomic symlink, what Nginx serves
  shared/                             # .env, storage/, persistent files
  tmp/                                # deploy inputs, cleared as it goes

Release directories are named after the time of the deploy. The five newest successful releases are kept. Older ones are removed at the end of each deploy.

Site isolation

Every site runs under a Unix user of its own. Its files belong to that account, and its PHP-FPM pool or systemd unit runs as it. On a server with several applications, each site's files and environment file are readable only by that site.

Nothing the site's account can write is loaded by root on its behalf. The site's Nginx includes live in /etc/nginx/provisore-sites/<domain>/, owned by root, and a systemd unit reads the site's .env through a copy taken as the site's own account each time it starts. Provisore moved every existing server to this layout once, without a deploy, and the server's activity log records when.

Symlink protection

Nginx follows a symlink under the site’s document root only when the link and the file it points to belong to the same account. The release symlink, Laravel’s public/storage link and anything the build creates all pass. A link to another site’s files or to a log answers 403.

It is on for every site. Turn it off under Settings, Symlink protection, when the site links to files another account owns; with it off, the site can publish any file Nginx can read. The change applies without a deploy, and the site’s audit log records who made it. For files on a volume, make the site the volume’s owner instead.

Deleting a site

Delete is at the bottom of the site’s Settings. It removes the Nginx configuration, services, and release directories from the server, then deletes the site. You type the domain to confirm.

If the server can no longer be reached, or an ordinary delete already failed, the API can force it with DELETE /v1/sites/{id}?force=true. That removes the site from Provisore only and leaves its files on the server. It still needs the domain, and a signed-in session also needs a recent password entry.