Git Deploy — Repository Management and CI/CD

[admin]

Git Deploy — Repository Management and CI/CD

Panelica includes a built-in Git manager that connects to GitHub, GitLab, or any Git remote. You can clone repositories, browse code, view commit history, and deploy directly from the panel.

---

Accessing Git Deploy

From the sidebar, click Git Deploy under the Applications section.

The interface is organized into tabs:

• Overview — Dashboard showing repository stats, recent deployments, and pipeline status.
• Repositories — List of all connected repositories.
• Deployments — History of all deployments across repositories.
• Pipelines — CI/CD pipeline configurations.
• Settings — System-level Git configuration.

---

Adding a Repository

Go to the Repositories tab and click Create Repository.

• Repository Name — A name for this repository in Panelica.
• Remote URL — The Git remote URL (e.g., https://github.com/user/repo.git).
• Branch — The branch to track (e.g., main or production).

Click Create to clone the repository to your server.

---

Repository Detail View

Click any repository to open its detail view with these tabs:

• Overview — Repository stats, current branch, last commit.
• Branches — View, create, delete, and switch branches.
• Commits — Full commit history with author, date, and message. Click any commit to see the diff with syntax-highlighted code changes.
• Files — Browse the repository file tree. Click any file to view its contents with syntax highlighting.
• Deployments — Deployment history with logs and rollback options.
• Environments — Manage deployment environments (e.g., staging, production).
• Pipelines — Configure CI/CD steps for automated deployment.
• Deploy Keys — Manage SSH keys for authenticated access to private repositories.
• Webhooks — Set up webhooks so GitHub or GitLab triggers automatic deployments on push.

---

Deploying Code

To deploy the current branch to your server:

1. Open the repository detail view.
2. Click the Deploy button.
3. Select the target environment.
4. Confirm the deployment.

The deployment log shows real-time output. If something goes wrong, you can roll back to any previous deployment from the Deployments tab.

---

Auto-Deploy

Each repository has an Auto-deploy toggle. When enabled, Panelica automatically deploys new commits pushed to the tracked branch. Combined with webhooks, this creates a fully automated deployment pipeline.

---

Notes

• The built-in code viewer supports syntax highlighting for JavaScript, PHP, Python, SQL, HTML, CSS, and more.
• Deploy keys are managed per repository — each repository can have its own SSH key for secure access.
• Rollback is instant — Panelica keeps previous deployment states for quick recovery.

 

[tailadmin]

Laravel gibi deploy yapılırken önceden var olan kullanıcının oluşturduğu içeriğin/dosyaların(.env ve storage, .gitignore'a dahil dosyalar) her deploy işleminde sıfırlanmaması için ne yapılması gerekiyor?

 

[admin]

Deployments mirror the repository into the target directory, which means anything the repository does not contain is removed from it — including files your application creates at runtime. Until now there was no way to protect them.

This is addressed in the current release. Repository settings now include a Preserve on deploy field. List one path per line:

.env
storage
public/uploads

Those paths are left untouched in the deploy target, and the deployment log states what was preserved. Pipeline deploy steps apply the same list, so a manual deploy and a pipeline deploy cannot behave differently. Repositories without a list keep the previous behaviour.

Paths are relative to the deploy target. Absolute paths and parent traversal are rejected, since an exclusion is meant to name something inside the target.

Requires Panel Backend 1.0.432 or later together with Panel Interface 4.5.282.

 

[tailadmin]

Korunacak dizinleri gireceğim bölümü bulamadım. Son güncellemeleri az önce yaptım. Panel güncel.
Ayrıca ortam bölümündeki Korunan özelliğinin ne işe yaradığını anlatan detay göremedim.
Benzer şekilde pipeline tanımlarken Shell komutu, Derleme, Test, Dağıtım, Bildirim seçimlerinin işlevleri nelerdir, dökümanda göremedim. 300 neyi temsil ediyor, depo köküne göre denilen yere bir dizin yazarsak terminali oradan mı başlatıyor?

 

[admin]

Thank you for the screenshots — they showed us two real defects, and both are fixed.

Why you could not find the field. "Preserve on deploy" was only rendered in the create-repository form, so an existing repository had no way to reach it. It now sits on the repository's Overview tab under Deploy settings, next to the deploy target, and the overview lists the preserved paths back to you. Separately, the value was not being written to the database when a repository was updated, so even an API call would have lost it. That is corrected as well.

The "Protected" switch you asked about. You were right to question it: it was recorded and drawn as a lock badge, but nothing read it. It now means what it says — a protected environment refuses unattended deploys from a webhook, and cannot be deleted until you turn protection off. Manual deploys and pipeline runs still work, because those are deliberate actions. The neighbouring "Auto deploy" switch now works too: a webhook push deploys to that environment as well, respecting its branch.

Pipeline step types. Shell command, Build and Test execute identically — the type only groups the stage in the run log. Deploy syncs the repository into the deploy target (honouring the preserve list), and can be bound to an environment to deploy to that environment's path instead. Notify writes a panel notification, using the command field as the message.

300 is the step timeout in seconds; the step is killed when it elapses.

"Relative to repository root" is the working directory the command runs in. Blank means the repository root; entering public runs the command inside public/. Write paths relative to that directory, not to the repository root — a command such as test -f public/build.txt with working directory public will fail for that reason.

Two further issues surfaced while we verified this end to end, and are fixed in the same update: a deploy no longer removes the panel's .user.ini or the .well-known/acme-challenge directory from the document root, and Rollback now restores the target exactly instead of unpacking the snapshot over the current files and leaving a bad deploy's additions behind.

The documentation has been rewritten to cover every tab and every switch on the page, including all of the above:

Git Deploy · Panelica Docs

Complete guide to Git Deploy in Panelica — repositories, branches, commits, file browser, deployments with snapshots and rollback, environments, pipelines, deploy keys, webhooks, OAuth connections and per-user isolation.

panelica.com

The panel changes are in the next update.