Hostnames in Config · Advanced · an hour
How to deploy a site with git — Keep the Hostname Out of the Repository
The deployment worked perfectly and the live site is now advertising your staging hostname in every canonical tag, sitemap entry and password-reset email.
The short answer
Commit the code and keep the environment out of it — and the most consequential piece of environment is the hostname. Staging and production are usually the same application differing by name, so a site address hard-coded in a committed file will follow the code from one to the other and quietly publish the wrong name.
Put the site address, the database credentials and the API keys in an environment file git never sees, use a read-only deploy key for the server, clone once and pull to deploy, and let a short script handle what happens afterwards.
An hour at advanced level. cPanel's Git Version Control does the server side from an interface if you would rather stay out of the terminal.
By the Hosting & Domains team · Reviewed 24 August 2026
Advanced
Level assumed
an hour
Time to allow
5
Stages in the guide
24/7
Desk cover
Deployment discipline is mostly about deciding what belongs in the repository and what does not. Code belongs. Secrets do not. Uploads and caches do not.
Hostnames sit in an awkward middle position, because they look like configuration and behave like content: they end up in canonical tags, sitemaps, emails, redirects and absolute URLs stored in the database.
Get the hostname handling right and staging stops leaking into production. Get it wrong and you will be running a search-replace across the database at an inconvenient hour.
What goes in, and what stays out
Code under version control, with uploads, caches and anything carrying credentials excluded. A .gitignore written properly on day one saves an embarrassing history rewrite a few months later. Database passwords and API keys belong in an environment file git never sees, so the repository is safe to clone anywhere without handing production's keys over with it.
Add the site address to that list. Whatever mechanism your application uses — an environment variable, a constant defined outside the repository, a per-environment config file — the hostname should be read at runtime rather than committed.
Why a committed hostname causes real damage
The hostname is not confined to one setting. It appears in canonical tags, in the sitemap, in password-reset and order-confirmation emails, in absolute URLs stored in post content, and in whatever your payment gateway holds as a callback URL.
Deploy a staging hostname to production and every one of those is wrong at once. Search engines index the staging name, reset emails send links nobody can use, and the gateway's callbacks go to a hostname that either does not exist publicly or is behind a password. The fix is a database search-replace and a cache purge, which is a poor way to spend an evening.
Deploy keys, clone once, then pull
A deploy key gives the server read-only access to one repository, which is narrower than an account key and revocable on its own. cPanel's Git Version Control arranges this from an interface for anybody who would rather not do it at the command line, and it is available alongside SSH and Composer on the developer plans.
The first deployment is a clone, either into the document root or into a directory beside it. Everything after that is a pull carrying only the changes, done in seconds. Then a short deployment script for dependency installs, a build step and a cache purge — run in the same order every time, which is the entire reason for working this way.
The first deploy onto a name that is not live yet
New sites are usually deployed before the name points at them, which is the moment a hostname baked into the repository does the most damage: the build is correct, the server is correct, and every generated link points somewhere that is not yet you. Read the hostname from environment configuration at deploy time and the same commit works on staging, on the temporary address and on the final name.
Do the cutover last and separately. Deploy, check the site on whatever address the host provides, then move the record. If anything is wrong afterwards it is a records question with a known answer, rather than a deploy and a DNS change failing together.
Git on the hosting, names in the panel
SSH, Git and Composer are on the developer plans, and cPanel's Git Version Control sets up the repository and the deployment from an interface, so a clone-and-pull workflow does not require moving to a VPS. Staging copies are available for trying a change before it reaches the live name.
The hostnames themselves — the staging subdomain, the production name, the records behind each — are configured in the same panel, alongside the registration. That is one place to confirm which name an environment is meant to be answering as.
- SSH, Git and Composer available on the developer plans
- Staging copies, for trying a change before it reaches the live name
- Records and registration behind a single login
- A daily copy taken, with restores you run yourself
Why Hosting & Domains
Standard on every plan
The hostname treated as environment
Read at runtime, never committed — because staging and production are usually the same code differing only by name.
The damage explained, not just the rule
Canonical tags, sitemaps, reset emails and gateway callbacks all carry the hostname, so a committed one is wrong in six places at once.
Secrets out of the repository
Credentials in an environment file git never sees, so the repository is safe to clone anywhere without shipping production's keys with it.
A narrow key for the server
A read-only deploy key scoped to one repository, revocable on its own rather than being an account key with everything attached.
No VPS required
cPanel's Git Version Control handles repository setup and deployment from an interface, alongside SSH and Composer on the developer plans.
The same steps every time
One short script for dependency installs, build and cache purge, run in a fixed order — which is the whole point of deploying this way.
Quick Start
Order placed to site online
- 1
Put the project in a repository with a real .gitignore
Code in; uploads, caches and anything carrying credentials out. Writing the ignore file properly on day one avoids rewriting history a few months later.
- 2
Move secrets and the site address out of the code
Database passwords, API keys and the hostname all belong in an environment file git never sees. The hostname especially, because staging and production differ by little else.
- 3
Set up a read-only deploy key on the server
Narrower than an account key and revocable on its own. cPanel's Git Version Control does this from an interface if you would rather avoid the terminal.
- 4
Clone once, then pull to deploy
The first deployment is a clone into the document root or a directory beside it. Every deployment after that is a pull carrying only the changes.
- 5
Script the post-pull work, then check the hostname
Dependency installs, build step, cache purge, in a fixed order. Then load the deployed site and confirm the canonical tags and emails name the correct hostname.
Built In
Fitted to every plan
- SSH, Git and Composer available on the developer plans
- Staging copies, for trying a change before it reaches the live name
- Nameservers, contacts, privacy and locks in one place
- A daily copy taken, with restores you run yourself
- PHP version set per site from the control panel
- Free SSL on every plan, reissued before the old one lapses
- A desk staffed every hour of every day
- The registration recorded in your own details
- A plan change applied to the account in place, with nothing migrated
- Thirty days' money back on hosting plans, seven on reseller
Frequently Asked
Questions we field again and again
My live site is showing the staging hostname after a deploy.
The site address was committed rather than read from the environment, so it travelled with the code. It will now be wrong in the canonical tags, the sitemap, outgoing emails and any absolute URLs the application stored in the database. Move the address into an environment file, run a serialisation-aware search-replace across the database, purge every cache layer, and then check the gateway's callback URL as well — that one fails silently.
Should the staging hostname be blocked from search engines?
Yes, and with a password rather than a robots rule. robots.txt is fetched per hostname, so the file on your live site never applied to staging in the first place, and a disallow only asks politely. Directory password protection refuses outright and keeps the staging copy out of the index whatever a crawler decides to do. It also stops a customer stumbling onto a half-finished version of your site.
Does shared hosting support Git deployment?
It does. Our cPanel plans include Git Version Control alongside SSH and Composer, so a clone-and-pull workflow works without moving to a VPS. For anybody who would rather not live at a command line, the interface handles repository setup and deployment.
Does everything belong in the repository?
The code yes; user uploads, generated caches and the database no. They change on their own schedule rather than with releases, so the backup routine is where they belong. Mix them in and the repository swells, while a rollback gains the power to destroy content it should never have touched.
Keep reading
How to Add TXT Records for Verification
Add the TXT records that prove ownership, and keep them where the zone can be read.
Web Hosting
cPanel hosting on NVMe, with Git Version Control alongside SSH and Composer.
Laravel Hosting
Laravel hosting, with the environment file kept firmly outside the repository.
Changing provider? Work through this checklist beforehand.
A straightforward running order for a migration your visitors never spot: which files travel first, how to bring the mail across without dropping a single message, the right moment to repoint DNS, and the two errors that sit behind almost every outage we get called in to fix.
Ship the code. Leave the name behind.
Git, SSH and Composer on the developer plans, staging copies before the live name, and a desk that answers at any hour.
View Web Hosting plans