Release engineering · Advanced · an hour to build, seconds to deploy
How to deploy a site with git — Deploy Into a New Directory and Switch a Symlink
Your deploy is a git pull into the live document root, which means every deploy has a window where visitors are browsing a half-updated codebase.
The short answer
Deploy into a fresh directory and switch a symlink, rather than pulling into the live document root. A pull that half-completes leaves visitors browsing a codebase where the new templates have arrived and the new classes have not; a symlink switch is a single filesystem operation, so the site is on the old release or the new one and never in between.
The rest of the design follows from that. A deploy key gives the server read-only access to one repository, the build steps run against the new release before it goes live, and rollback stops being a git operation at all — you point the symlink back at the previous directory, which is still sitting there intact.
By the HostingFast team · Reviewed 24 August 2026
Advanced
Level assumed
an hour
Bench time
5
Stages to work through
24/7
Cover, round the clock
An hour to set up, seconds per deploy afterwards. This assumes a shell on the server; cPanel's Git Version Control covers the same ground from an interface if you would rather not use one.
The measurement here is the window: how long the site spends in an inconsistent state during a deploy. With a pull into the document root it is however long the transfer takes. With a symlink switch it is one atomic operation, and that difference is the entire argument.
What goes in the repository, and what never does
Track the code. Exclude uploads, caches, compiled assets you can rebuild, and anything holding a credential. A .gitignore written properly on day one saves a history rewrite and a round of secret rotation several months later, when somebody notices the database password in an old commit.
Configuration belongs in an environment file the repository never sees. The test is simple: the repository should be safe to clone onto a laptop without handing over production. If cloning it gives somebody your database credentials and your API keys, the boundary is in the wrong place.
Access on the server, narrowed
A deploy key gives the server read-only access to exactly one repository — narrower than an account key, and revocable on its own without disturbing anything else you have access to. Generate it on the server, add the public half to the repository, and never reuse it across projects.
cPanel's Git Version Control arranges the clone and the pull from an interface, which is the right choice if the alternative is nobody deploying because the terminal is unfamiliar. SSH, Git and Composer are on the developer-focused plans either way, so both routes are available on the same account.
Release directories and the symlink switch
Clone into releases/timestamp rather than into the document root. Run the build there — composer install --no-dev --optimize-autoloader, the asset pipeline, whatever your stack needs — while the current release carries on serving traffic. Nothing user-facing has changed yet.
Then switch: point the document-root symlink at the new directory. That is one atomic filesystem operation, so there is no window where half the files are new. Shared directories — uploads, logs, the environment file — live outside the releases and get symlinked in, which is what makes the previous release a complete, working thing you can go back to.
What has to happen after the switch
Reset the opcode cache, or the server will keep executing the previous release's compiled PHP from memory and you will spend twenty minutes convinced the deploy failed. Then purge the page cache, run migrations if the release needs them, and warm anything expensive before traffic finds it cold.
Keep the last few release directories and tag each one. Rollback is then pointing the symlink back and resetting the cache again — seconds, at six in the evening, with no thinking required. Our staging clones let you rehearse the whole sequence on a copy first, and the daily backup sits behind it as the last resort you should never need.
What the platform gives a deploy
SSH, Git and Composer are on the developer-focused plans, with cPanel's Git Version Control there if you would rather click than type. Staging clones let you rehearse a release sequence on a copy of the site before it touches production.
Mailboxes on your own domain come as part of the plan — email is included rather than sold back to you at checkout.
- SSH, Git and Composer on the developer-focused plans
- cPanel Git Version Control for clone-and-pull from the panel
- Staging clones for rehearsing the release sequence
- Daily backups you restore yourself, as the last resort
Why HostingFast
Standard on every plan
No half-deployed window
A symlink switch is one atomic operation, so visitors get the old release or the new one and never a mixture of both.
Build before you switch
Dependencies and assets are compiled in the new release directory while the current one carries on serving traffic.
Rollback without git
The previous release is still on disk. Pointing the symlink back is seconds, which is what you want at six in the evening.
Access scoped to one repository
A read-only deploy key, revocable on its own, rather than an account key that reaches everything you own.
The opcache step included
The reset that stops the server serving the previous release's compiled PHP, which is the classic 'the deploy did not work' twenty minutes.
Both routes supported
Shell for those who want it, cPanel Git Version Control for those who do not — on the same account, on the same plans.
Quick Start
From order to online
- 1
Get the repository boundary right
Code tracked; uploads, caches and credentials excluded. The repository must be safe to clone onto a laptop without handing over production.
- 2
Add a read-only deploy key
Generated on the server, scoped to one repository, revocable on its own. cPanel's Git Version Control does the same job from the panel.
- 3
Clone into a timestamped release directory
Never into the live document root. Shared directories — uploads, logs, the environment file — live outside releases and get symlinked in.
- 4
Build, then switch the symlink
composer install --no-dev, the asset pipeline, migrations if needed. Then repoint the document-root symlink: one atomic operation, no half-deployed window.
- 5
Reset opcache and keep the last few releases
Clear the opcode cache and the page cache, tag the release, and leave the previous directories on disk so rollback is a symlink away.
Built In
Loaded onto every plan
- SSH, Git and Composer on the developer-focused plans
- Staging environments for rehearsing a change before it ships
- Per-site PHP version switching from the control panel
- Daily backups on every plan, with restores you run yourself from the panel
- NVMe SSD storage on every tier, including the entry plan
- cPanel — the control panel most of the industry already runs
- LiteSpeed caching compiled into the server, not bolted on by plugin
- Email addresses that run on your own domain name
- In-place account upgrades, with no migration when you change plan
- Human support on duty every hour of every day
Frequently Asked
What people ask us most often
Why does pulling straight into the live document root cause errors?
Because a transfer takes time and the site is being served throughout it. For those seconds some files are from the new commit and some from the old, so a template can call a class that has not arrived yet. Deploying into a separate release directory and switching a symlink removes the window entirely rather than shortening it.
Does OPcache need clearing after a deploy?
Yes, or the server keeps executing the previous release's compiled bytecode from memory and your change appears not to have happened. It is the most common cause of the twenty minutes people spend re-running a deploy that already worked. Put the reset in the deployment script so it is never the thing you forgot.
How do I roll back in one command?
Point the document-root symlink back at the previous release directory and reset the opcode cache. That is why the old releases stay on disk and why shared directories live outside them — the previous release is a complete, working install, not something you have to reconstruct from git history under pressure.
Can I run Composer on shared hosting?
On the developer-focused plans, yes — SSH, Git and Composer are included, so you can clone, install dependencies and deploy without renting a server. If you would rather not use a terminal at all, cPanel's Git Version Control handles the clone and the pull from the panel and works on the same account.
Keep reading
How to Add TXT Records for Verification
Prove domain ownership to Google, Microsoft or any service that asks, and check the record resolved — beginner, roughly 5 minutes per service.
How to Add Google Analytics
Install the tag once, prove it fires once, gate it behind consent, then measure its cost — beginner, roughly 30 minutes.
Git (Glossary)
The version-control system underneath all of this, and the concepts a deploy actually depends on.
Web Hosting
cPanel hosting on NVMe behind a LiteSpeed cache — SSL, migration and a year-one domain included.
Laravel Hosting
Laravel-ready hosting with Composer, SSH and Git-driven deploys.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Deploy from a repository, not a file manager.
SSH, Git and Composer on developer plans, cPanel Git Version Control in the panel, staging clones and daily backups behind every release.
View Web Hosting plans