Operator's Guide
Hosting with git deployment — One release process, twenty client sites, and a rollback nobody has to explain
Written for teams shipping changes to sites they do not own — where the deployment question is really a question about keys, permissions and what the client inherits.
Straight answer first
Standardise on a plan with SSH and Git already fitted — a Pro plan does it — keep a clone on the server for every site you maintain, and release with a pull, so that the same three commands work on every account you administer.
The part that separates an agency arrangement from a personal one is ownership. The repository, the deploy key and the build step all outlive the engagement, and if none of them is documented the client is left with a running site nobody can change. Decide that at setup, not at handover.
Written by the Hosting Seller staff · Checked 24 August 2026
NVMe
Disk under every account
Free
Domain for the first year
99.9%
Uptime target we hold
Flat
Cost across the renewal
Deployment discipline is really rollback discipline wearing different clothes. On your own site that is a matter of taste. Across sites you are paid to keep running, it is the difference between a bad release costing four minutes and costing an afternoon of apologies.
The version-controlled route also changes what a fault call sounds like. 'Which files did I change on Tuesday' is not a question anybody can answer from an FTP client, and it is the question that turns a small mistake into a long evening.
Deploy keys, and whose key it actually is
A deploy key sits on the server and reads from the repository. The question nobody asks at setup is which account it belongs to — the agency's shared machine user, the individual developer, or the client's own organisation. All three happen, and only one of them survives a staff change without incident.
Issue a read-only deploy key per site rather than a single key with access to everything. It costs a minute per account and it means a compromised server, or an account handed over to a new supplier, does not carry access to the rest of your work.
Keep an inventory. Which site pulls from which repository, on which branch, using which key. Three columns in a document is enough, and it is the document you will want the week a developer leaves.
Making the same release work on every account
Standardise the layout before you standardise the tooling. If every account keeps the clone in the same place relative to the document root, the deploy command is identical everywhere and can be run from a script, from a hook or by whoever is on shift.
The simplest arrangement that scales: clone over SSH into the account, point the domain at that directory, and release with a pull. Add a post-receive hook later if push-to-deploy starts to appeal — but do it after the layout is uniform, not before.
Where a build step is involved, decide whether it runs on the server or produces an artefact you commit. Both are defensible; what is not is having half the fleet on one convention and half on the other, because that is how a Friday release goes to the wrong site.
The rollback the client never has to hear about
The value of the whole arrangement is that a bad release is reversible in seconds. Check out the previous tag or commit and the site is back where it was, with no restore, no ticket and no conversation.
Keep the database out of that story deliberately. Code rolls back cleanly; orders taken in the last ten minutes do not. Decide per site whether a release ever touches schema, and if it does, take a dump first — from the same shell you are already in.
Daily backups sit underneath as the second net, with restores you run yourself from the panel. Version control handles the changes you made on purpose; the backup handles the ones you did not.
Handover: what the client inherits
Write down, at the start of the engagement, what happens to the repository when the engagement ends. The honest options are that the client's organisation owns it and grants you access, or that you own it and undertake to transfer it on request. Both are workable; the unstated third option is how disputes start.
Practically, handover means transferring or forking the repository, reissuing the deploy key under the client's control, and moving the hosting account itself. Because the site lives in its own cPanel account on a reseller arrangement, that last part is a migration rather than an extraction.
Leave a page of documentation in the repository: where the clone lives, which branch deploys, what the build step is, and how to roll back. It takes twenty minutes and it is the single thing that decides whether you are remembered well.
Where our interest sits in this
We sell the hosting this describes, which we would rather state than disguise as impartial research. The specifics are the useful part — they can be checked against any supplier, including us.
SSH, Git and Composer are standard on these plans rather than a premium tier, because an account you cannot deploy to cleanly generates support tickets for both sides of the counter.
- Git and Composer present at account creation
- A clone per account, released with a pull
- Read-only deploy keys issued per site
- Daily backups underneath as the second net
Why Hosting Seller
On every plan, as standard
The same commands everywhere
A uniform layout across accounts means one deploy procedure covers the whole fleet, whoever happens to be running it.
Rollback measured in seconds
Checking out the previous tag puts the site back where it was, with no restore ticket and no conversation with the client.
Keys you can revoke individually
A read-only deploy key per site means a departing developer or a handed-over account never carries access to the rest of your work.
Handover as a migration
Each site in its own account means transferring it is moving an account, not extracting a folder from a shared filesystem.
Backups underneath the release
Daily backups with self-service restores cover the changes version control was never meant to reverse.
A cost you can quote inside a retainer
The renewal figure matches the joining figure, so a fixed monthly price does not quietly stop working in year two.
Price Tags Compared
How we compare with the household names
Typical sign-up and renewal prices across the market, set next to ours — the second number most comparison charts leave off.
| Line item | Hosting SellerBest seller | Typical big-brand host | Typical budget host | Typical loss-leader |
|---|---|---|---|---|
| Entry price / mo* | $2.42/mo | $4–$6 | $2–$4 | $1–$3 |
| Price at renewal / mo | $2.42/mo | $10–$15 | $8–$12 | $4–$6 |
| Renewal price on the entry plan is unchanged | ||||
| SSL on every plan | ||||
| Site migration included | ||||
| The entry plan uses NVMe storage | ||||
| Entry plan gets a backup daily | ||||
| Live human support, 24/7 |
*The number in our column is the cheapest plan on our shelf, priced on an annual term and pulled live from the very catalogue that feeds the pricing page, so it cannot drift out of date. Other columns show the ranges shared hosting tends to advertise inside each bracket: introductory rates that normally ask for a one-to-four-year commitment, then climb once that term expires. Naming individual competitors and printing their prices is something we have stopped doing. A figure we cannot re-check on the day you read it has no business sitting in front of you. So compare us with whoever you are genuinely weighing up, and read the renewal line first. That line tells you more than the headline ever will.
First Steps
From choosing to live
- 1
Fix the directory layout before the tooling
Decide where the clone lives relative to the document root and apply it to every account. Uniformity is what makes a deploy script safe to run without checking which site you are on.
- 2
Issue a deploy key per site, read-only
One key per repository per account. It takes a minute at setup and is the reason a compromised server or a transferred account does not become an incident across the fleet.
- 3
Write the handover clause at the start
Who owns the repository, and what transfers on request. Agreeing it while everyone is cheerful takes five minutes; agreeing it afterwards takes a solicitor.
In the Box
Packed with every plan
- Git present on the account without a support ticket
- SSH available at creation to drive the deploy
- A read-only deploy key issued per site
- A uniform clone location across every account
- Composer available for framework dependency installs
- PHP chosen per site, so a build step targets the right runtime
- Daily backups with restores run from the panel
- Staging available for rehearsing a risky release
- Account-level migration when a site is handed over
- The renewal figure printed next to the joining figure
Across the Counter
Things people ask us all the time
Should each client site have its own deploy key?
Yes, read-only, one per site. A single key with access to every repository is convenient until the day an account is handed to another supplier or a server is compromised, at which point it is access to all of your work rather than one site's. The cost of doing it properly is about a minute per account.
Who owns the repository when the engagement ends?
Whoever you agreed at the start, which is why it needs agreeing at the start. Either the client's organisation owns it and grants you access, or you own it and undertake in writing to transfer it on request. The version where nobody decided is the one that produces a dispute over an asset the client believes they paid for.
Is a post-receive hook worth setting up across a fleet?
Only after the layout is uniform. Push-to-deploy is pleasant when every account is arranged identically and dangerous when they are not, because the failure mode is deploying to the site you were not thinking about. Standardise the directory structure first, automate second.
What should a client be left with at handover?
The repository or a transfer of it, a deploy key under their control, the hosting account itself, and a page of documentation naming the clone location, the deploying branch, the build step and the rollback command. The documentation is the cheapest item on that list and the one that decides how you are described afterwards.
Read next
Dedicated Server Value
Bare-metal control priced against what it actually costs to administer, rather than against a spec sheet.
VPS vs Dedicated Servers
Sizing a serious workload against a budget you have to justify to somebody else.
Business Hosting
Shared hosting with the developer kit: SSH, Node.js, Python and PostgreSQL on one account.
Laravel Hosting
Composer, SSH and Git deploys on hosting shaped around what Laravel actually asks for.
Moving your site to another host? Start with this checklist.
A step-by-step order of work for a move your visitors never spot: which files to copy first, how to carry email across without losing one message, the right moment to repoint DNS, and the two mistakes behind nearly every hour of downtime people ring us about.
Standardise the deploy across every account.
SSH and Git fitted at creation, a clone per account, daily backups underneath, and a price that holds at renewal.
See Business Hosting plans