All documentation
Getting started

Introduction

Provisore sets up and runs Ubuntu servers you rent yourself, for Laravel, PHP, Node, static and Swift applications. It works over SSH, and everything it configures is standard Ubuntu you can still manage by hand.

What it does for you

You rent a server from Hetzner, DigitalOcean, AWS or anyone else, and connect it with one command. From then on Provisore does the server work over SSH. It locks down SSH and the firewall, installs the runtime each site needs, writes the Nginx configuration, issues Let’s Encrypt certificates and tells you before one lapses, deploys from Git behind a health check, and keeps your queue workers and cron jobs running. On Hetzner it can create the machine as well.

What it writes is standard Ubuntu: systemd units, Nginx vhosts, files under /etc/cron.d, and a deploy user. Your sites keep serving if you stop using Provisore, and you can log in and change any of it yourself.

When something breaks, it lands on Today with the fix beside it: a failed deploy to run again, a certificate to retry, a stopped worker to restart. Finding your way around walks through the app.

Core concepts

  • Team. Everything belongs to a team: servers, sites, tokens, and the subscription. You can belong to several.
  • Server. A VPS you connected. Provisore provisions it once and manages it after that.
  • Site. An application on a server, bound to a domain, a repository, and a runtime.
  • Deployment. A release built in its own directory and activated with a symlink swap. Nothing changes a release after it is built.
  • Job. Any long-running operation, such as a provision, deploy, backup, or restore, with output you can follow live.

Quick start

  1. Create a fresh Ubuntu 24.04 or 26.04 LTS server at your provider, or connect a Hetzner Cloud token and let Provisore create one.
  2. Connect it with the one-line command.
  3. Create a site from a Git repository.
  4. Deploy it. A repository connected through the Provisore GitHub App deploys as soon as the site exists, and on every push once you turn on deploy on push. For any other repository, add the site’s deploy key at your Git host, then press Deploy or call a deploy hook from CI.
  5. Point DNS at the server and issue a certificate.

Where to go next

  • Runtimes covers what Laravel, PHP, Node, static, and Swift sites each build and run.
  • Backups do nothing until you point them at a bucket you own.
  • Every new server gets default disk and memory alert rules. An alert reaches you only through a notification channel you add.
  • Moving off Laravel Forge? Migrating a server recreates its sites, databases, cron entries and daemons.
  • The REST API is the one the app uses, so scripts and CI can do most of what you do by hand.