NovaPanel
Features Pricing NovaPanel VPS · soon Alternatives Docs Changelog Customer portal Discord GitHub
Get Pro
Docs

Deploy from Git

Point a site at a Git repository, rebuild it on every push, and roll back to the previous version in one click.

What this does

A site can be built straight from a Git repository. NovaPanel clones your branch, runs the build for the site's runtime, and swaps the result into the document root only once it has been built successfully — so a failed build never takes the live site down.

Two things make it worth wiring up properly: push-to-deploy, so a push rebuilds the site with no one watching, and rollback, so a bad commit is one click away from being undone.

Connect a repository

Customer panel → Git Deploy. Pick the site, then set the repository URL and branch in Site Settings.

For a private repository, use an SSH deploy key. On the Git Deploy page, press Generate new key and add the public key to your repository's deploy keys (GitHub: Settings → Deploy keys → Add deploy key; GitLab: Settings → Repository → Deploy keys). Read-only access is enough. Then set the repository to its SSH address, such as git@github.com:you/repo.git. To use a key you already have instead, press Use my own key and paste the private key (without a passphrase). The private key stays on the server and is never shown again.

Repository addresses with a token in them (https://user:token@…) still work, but a deploy key is safer: the token never appears in deploy logs (from 1.9.7 it is hidden as ***), and a deploy key can only read that one repository.

PHP sites are built with the site's own PHP version: composer and the custom deploy command use it, and the deploy log says which version ran. Composer runs before the new files go live, so a failed install fails the deploy and leaves the live site untouched. A site's .env and storage/ folder are kept across deploys.

Turn on push-to-deploy

The Git Deploy page shows a webhook URL for the site. Copy it and add it to your repository:

  • GitHub — Settings → Webhooks → Add webhook. Paste the URL, content type application/json, and leave it on "just the push event".
  • GitLab — Settings → Webhooks. Paste the URL and tick Push events.

That URL contains a secret unique to the site, so treat it like a password — anyone holding it can trigger a deploy of that site. If you ever need to invalidate it, it is regenerated when the site's deploy settings are reset.

A push while a deploy is already running is skipped rather than queued twice, so a busy repository will not stack builds on top of each other. You get a notification either way, because nobody is watching the panel when a push lands.

Roll back a bad deploy

NovaPanel keeps the previous version of the document root. On the Git Deploy page, Restore previous version puts it back.

The rollback is instant: it does not rebuild, and it does not need the network or your Git host, which matters because a rollback is usually what you reach for when something is already broken. The version being replaced is kept, so a rollback can itself be undone.

For Node and Python sites the app is restarted and the web server repointed automatically as part of the rollback.

When the button is not there

Rollback appears only when a previous version actually exists on disk. It will not be there before the site's second deploy, or if the .nova-previous folder in the site directory was deleted over SFTP. Showing a button that would fail is worse than not showing one.

Custom build steps

On the Developer tier you can set a deploy command per site — run migrations, clear a cache, or perform any extra build step. It runs in the document root as the site's own Linux user, the same user and directory you already have over SSH.

What gets served

Version-control metadata is stripped from the document root on every deploy, and .git, .env and similar paths are refused by the web server. A repository's history — and any password ever committed to it — is never reachable from the site.