Laravel Git Blog - Self-hosting

Backing Up Your Git Server So It Actually Restores

Wed, 21 Oct 2026 00:00:00 GMT

Self-hosting your Git means the server is the canonical copy. Developers' clones soften the blow of losing it - every clone has the history - but a clone is not a backup of the server: hooks, server config, access rules and anything outside the refs live nowhere else. A backup plan has to cover both, and it only counts if a restore has been rehearsed.

Mirror the repositories

git clone --mirror git@yourserver:app.git

A mirror clone copies every ref - branches, tags, notes - and none of the working-tree state. To refresh it:

git -C app.git remote update

Two lines in a nightly cron and every repository on the server has a current, complete copy somewhere else. On a small server, loop over the bare repos directory and mirror each one.

Bundle for portability

For a single-file, copy-anywhere backup of one repo:

git bundle create app-2026-10-21.bundle --all

A bundle is a real Git pack: git clone app-2026-10-21.bundle app reconstructs the repository on any machine with Git and nothing else. Bundles are the right shape for weekly off-site copies - one dated file per repo, uploaded to object storage or another box.

Copy what Git does not track

The repositories are the obvious half. The other half lives next to them: server hooks (your deploy and protection scripts), the Git host's own configuration, user and access data. A plain rsync -a of those directories into the same off-site destination covers it. Losing the repos is painful; losing the hooks and config is what turns a restore into a rebuild.

Rehearse the restore

A backup you have never restored is a hope, not a plan. Once a month, pick one bundle or mirror and restore it to scratch space: clone from it, run the test suite, check the latest commits are there. Ten minutes, and the night the server actually dies becomes an inconvenience instead of an incident.

The honest summary: mirror nightly, bundle weekly off-site, rsync the config, restore monthly. Four small habits, and the machine your whole team depends on stops being a single point of failure.

Monitoring Your Self-Hosted Git Server: The Four Things That Matter

Wed, 21 Oct 2026 00:00:00 GMT

Hosted Git comes with someone else's pager. Self-hosted means the pager is yours - which is fine, as long as it only rings for real problems. Four checks cover every failure mode a small team's Git server actually has, and none of them requires a monitoring platform you will spend a weekend configuring.

1. Is it answering?

An external uptime check hitting the web interface every minute, from outside your network. This catches the server being down, the reverse proxy dying, and the certificate expiring. Any ping service does this for free or close to it. Alert on two consecutive failures, not one - single blips are network weather.

2. Can someone actually clone?

The web UI can be green while SSH is dead, and your team notices at 9am Monday. A synthetic check that runs git ls-remote against a small repo every few minutes exercises the path that matters - SSH auth, Git daemon, disk read. A cron job on another machine with a dedicated read-only key (the deploy keys guide covers scoping it) is thirty lines of setup.

3. Is the disk filling up?

Repos only grow, and a full disk corrupts things in the order you least want. Alert at 80%, not 95% - the gap between "we should prune something this week" and "pushing is failing right now." Watch the backup destination too; it fills up quieter.

4. Did the backup actually run - and restore?

The backup cron succeeding means a file was written, not that it restores. Backing up your Git server covers the backup half; the monitoring half is two alerts: one when the backup job misses its window, and a monthly drill where you restore to a scratch machine and clone from it. The drill is the only check on this list that cannot be automated away, and the only one that proves the rest mean anything.

Four checks, one drill, and the pager stays silent for months at a time - which is exactly what "the server is fine" should feel like.

Moving Your Repositories to a New Git Server Without Losing Anything

Wed, 21 Oct 2026 00:00:00 GMT

Moving hosts feels risky because the repo is the crown jewels. The good news: Git is a distributed system, and every clone already contains the complete history. Migrating is mostly a matter of pushing that history somewhere new - plus remembering the things that are not in the repo.

The mirror push

The recipe for a lossless move is three commands:

git clone --mirror git@old-host:your-org/your-app.git
cd your-app.git
git push --mirror git@new-host:your-org/your-app.git

--mirror on the clone fetches every branch, every tag, every note - not just the default branch checkout. --mirror on the push replicates all of it, exactly, onto the new server. When the push finishes, the new repo is a bit-for-bit copy of the old one's refs. History, tags, branches: done.

What does not travel

The repository is only part of what makes a project work. Plan separately for:

Pull requests and issues. These live in the host's database, not in Git. GitHub's API can export them; some teams archive them to a document and start fresh, some use migration tooling. Decide consciously - do not discover the gap after the cutover.
CI secrets and variables. Re-enter them on the new side. This is also a natural moment to apply the scoping rules from deploy keys and machine users instead of copying an old personal key.
Webhooks and integrations. Deploy hooks, Slack notifications, status checks - make a list before you start, and tick each one off on the new server.
Branch protection rules. Recreate them; branch protection rules that stick is the checklist.

The order that avoids pain

Set up the new server and recreate protections while the old one still serves everyone.
Mirror-push every repo, and spot-check: clone from the new host, run the test suite, compare git log on a few branches.
Move one non-critical repo first as a dress rehearsal for the team's workflow changes.
Announce a short freeze on the old host, do a final mirror push to catch the last commits, then update everyone's remotes: git remote set-url origin git@new-host:your-org/your-app.git.
Keep the old host read-only for a month. Deleting it on day one is how you find out what you forgot.

If you are moving to self-hosted, the prep work is the same - plus the operational habits in backing up your Git server from day one, because the safety net is now yours to run.

The history is the easy part; Git was built for this. The checklist above is the difference between a quiet migration and a week of "did anyone move the webhook?"

Private Composer Packages Straight From Your Own Git Server

Wed, 21 Oct 2026 00:00:00 GMT

Every growing Laravel team eventually extracts a package: the shared billing client, the internal logging helper, the theme. Then comes the assumption that serving it needs infrastructure - Satis, Private Packagist, a registry. For most teams it does not: Composer reads plain Git repositories directly, and if you already self-host your Git, the registry is running.

The VCS repository

In the consuming app, tell Composer where the package lives:

"repositories": [
    { "type": "vcs", "url": "git@git.yourcompany.com:shared/billing-client.git" }
],
"require": {
    "yourcompany/billing-client": "^1.2"
}

The package repo itself just needs a composer.json with its name and autoload config - no extra hosting. On install, Composer clones the repo over SSH and checks out the requested version. That is the whole registry.

Versions come from tags

Composer reads versions from Git tags, which makes disciplined tagging the whole game: tagging releases properly covers annotated semver tags, and the contract here is simple - tag 1.2.0 in the package repo and ^1.2 resolves to it. No tag, no release; a branch name works for dev versions (dev-main) but treat that as a development convenience, never a production dependency.

Access is the only real setup

CI and every developer need read access to the package repo. This is where teams reach for a shared key in a wiki - do not. The patterns in deploy keys and machine users apply exactly: a read-only deploy key per consumer, or a machine user with access to the package repos. Developers authenticate with their own SSH keys, which they already have.

When you outgrow it

The direct-VCS approach slows down at scale: Composer clones every package repo on every install, and metadata lookups multiply. The honest thresholds are dozens of packages or very slow CI installs, and the upgrade path is Satis (static, self-hosted, stays on-brand) generating metadata over the same repos. Until then, VCS entries plus tags cover the need with zero new infrastructure.

Your Git server already hosts the code. Let it host the packages too.

Server-Side Git Hooks Worth Running on Your Own Server

Wed, 21 Oct 2026 00:00:00 GMT

Local hooks (the kind in git hooks for Laravel projects) run on the developer's machine, which means they run only when the developer kept them installed. Server-side hooks run on every push, for everyone, no exceptions. When you self-host, they are one of the best reasons to - and one of the easiest ways to annoy your team if you overreach.

Three checks that earn their place

1. Block the secrets. A pre-receive hook scanning pushed commits for private keys, .env contents and common token shapes turns a secret got committed from an incident into a rejected push. Gitleaks or a few good regexes; the point is that the secret never lands in the repo's history at all, which is when cleanup is free.

2. Protect the default branch. Even with branch protection rules configured in the UI, a pre-receive or update hook rejecting direct pushes to main is the belt to the platform's suspenders - it still fires if someone widens a permission by mistake.

3. Refuse giant blobs. A 200MB binary committed once lives in every clone forever. Rejecting pushes with files over a sane limit (100MB is GitHub's line; yours can be lower) pushes large assets to Git LFS before they become permanent.

The restraint that keeps them tolerable

A rejected push interrupts someone mid-flow, so every hook owes them three things:

A fast answer. A hook that scans ten thousand commits on every push will be bypassed, not loved. Check the pushed range, not all of history.
A message that says how to fix it. "Push rejected: possible secret in src/config/legacy.php (line 41). Remove it, rewrite the commit, see ." A bare "rejected" teaches people to fear the server; a clear one teaches them the rule.
A real escape hatch. False positives happen - a test fixture that looks like a key, a legitimate big file. Someone on the team should be able to bypass with a reason, and that bypass should be logged, not forbidden.

Start with the secret scanner; it has the best ratio of one-time setup to incidents prevented. Add rules the way you add tests: when the failure actually happens, not in anticipation of every imaginable one.

Deploying a Laravel App With Git Push

Mon, 19 Oct 2026 00:00:00 GMT

Self-hosting your git and your app on the same box has a nice property: a push can be the deploy. You need a bare repository and one hook.

The bare repo

git init --bare /srv/git/myapp.git

Add it as a remote on your laptop and push a branch you deploy from, for example main.

The post-receive hook

/srv/git/myapp.git/hooks/post-receive, made executable:

#!/bin/bash
set -e
APP=/var/www/myapp
git --work-tree=$APP --git-dir=/srv/git/myapp.git checkout -f main
cd $APP
composer install --no-dev --optimize-autoloader
php artisan migrate --force
php artisan config:cache
php artisan route:cache
php artisan view:cache

checkout -f syncs the working tree to the pushed commit. The artisan steps are the boring, repeatable part of every Laravel release.

Keep it honest

Run the hook as a user that owns /var/www/myapp but cannot sudo.
migrate --force runs unattended, so only push migrations you have tested against a copy of production data.
If the hook fails, the push still lands in the repo; redeploy by pushing an empty commit or rerunning the hook on the server.

This is one step above "SSH in and pull". When you outgrow it — zero-downtime releases, rollbacks, multiple servers — that is the point where a real pipeline earns its keep, not before.

Why Teams Self-Host Their Git

Thu, 15 Oct 2026 00:00:00 GMT

Hosted Git is convenient. Self-hosting is about control.

Know where the code lives

Repositories sit on servers you run. You decide on backups, retention and who gets in.

Set your own access rules

Give people the access their role needs and remove it when they leave.

Keep it simple

Self-hosting only pays off if it stays easy to run. Pick tools you can update without a project.