Git Deploy
Git Deploy turns "push to deploy" into a panel feature: connect a repository, point it at a domain's document root, and every deploy is pulled, snapshotted and synced with a one-click rollback waiting if it goes wrong. Webhooks close the loop so a push to GitHub or GitLab deploys automatically.
Git Deployhttps://YOUR-SERVER-IP:8443/git/manager| Repository | Branch | Status | Auto-deploy | Last commit | Actions |
|---|---|---|---|---|---|
| company-site github.com/acme/site | main | active | ON | feat: new pricing | view · pull · delete |
Repositories
Adding a repository is a three-step wizard: pick the source (GitHub, GitLab, Bitbucket, a custom remote, or a local repository created empty on the server for pushing to over SSH), enter the URL, name and branch with an auth method for private repos: a personal access token, or an OAuth connection saved once under Settings and reused across repositories. Step three picks the deploy target: none (just a repo), a domain or subdomain's document root (with one-click /app and /public variants), or a custom path for advanced setups.
Repository rows show status, branch, last commit and an auto-deploy switch; actions cover pull, fetch and delete. Admins and resellers create repositories on behalf of a chosen user; quotas from the hosting plan cap how many repositories an account may have.
.panelica-git tree, and every git command runs as the owner's Linux user, never root. Tokens are stored encrypted, injected into the remote URL only for the duration of a pull and scrubbed from logs. Clones run in the background with live status; a wrong branch is detected and corrected rather than failing the repo.The repository view
Opening a repository reveals the full workbench in tabs: an Overview with the repo's facts (local repos include a push-over-SSH cheat sheet), Branches (create, checkout, delete, with HEAD protection), Commits with a GitHub-style diff viewer (per-file collapse, keyboard navigation), a read-only file browser with syntax-highlighted viewing and per-file download, Deployments with expandable logs, Environments (additional deploy targets, each with its own branch and path, for staging-style setups), Pipelines, Deploy Keys (the panel generates an ed25519 keypair and shows the public key to register at your provider), and Webhooks.
Deploying, safely
Deploy runs a fixed, transparent sequence: pull the latest, take a tar.gz snapshot of the current target, sync the repo over it (excluding .git, node_modules and vendor), fix ownership and permissions, and record the deployed commit. Every deployment row keeps its log; failed or regretted deploys offer Rollback, which itself snapshots the current state before restoring the previous one. The last five snapshots are retained per repository.
Pipelines add custom automation: named steps of type shell, build, test, deploy or notify, each with its command, working directory, timeout and a continue-on-error switch, triggered manually or by branch. Steps run as the owner's user with the same path protections as deploys.
Webhooks make it hands-free: create one per provider and the panel shows the endpoint URL and a secret exactly once. Pushes signed with that secret (verified via HMAC for GitHub, header token for GitLab) trigger an automatic deploy when the repository's auto-deploy switch is on. Prepend your panel's address to the shown path when registering the hook at the provider.
Access
Git Deploy is a licensed feature (git) with the panel's most granular permission set: repos, branches, commits, diffs, downloads, deploys, rollbacks, environments, pipelines, deploy keys, webhooks and OAuth connections each carry their own keys. Data visibility follows the roles and permissions chain: a USER sees only their own repositories, while ADMIN and RESELLER create on behalf of a chosen customer and see their chain. Installing the Git package itself is a one-time ROOT action offered right on the page (other roles see a note to ask an administrator).