DNS Buyer's Brief
Hosting with git deployment — Version control gives you an undo. Your zone does not.
You can put last week's code back with one command, but the record you changed in the same hour is now sitting in resolver caches nobody at your end controls.
The short answer
Buy a plan with SSH and Git fitted as standard so a release becomes a pull rather than a file drag — then keep releases away from DNS changes, because code has a genuine undo and a cached record does not.
That is the part the deployment guides leave out. Reverting a bad release is a checkout against the previous tag and the site is back where it stood a minute ago. Reverting a bad record means waiting out every cache that already answered with it. One is instant and yours; the other is a timer somewhere else.
By the Hosting & Domains team · Reviewed 24 August 2026
NVMe
Storage on every plan
Free
Year one of the name
99.9%
Uptime, monitored
Flat
Renewal figure
This page is for developers who are finished dragging files into an FTP window, and who also happen to be the person holding the domain.
The strongest argument for version-controlled deployment is traceability: every change stays reversible, which an overwrite-based workflow cannot structurally offer at any price. The argument this page adds is that the same is not true of the address, so the two jobs should never share an afternoon.
Two systems, two very different undos
A repository holds every state your code has been in, so going back is a command. DNS holds one current answer, plus however many stale copies are still living out their TTLs in caches around the world. Caching is the entirety of what people call propagation, and it runs on the timer you set before the change, not after it.
Which means the release you can fix in seconds and the record you cannot fix for hours should not be changed in the same window. When something breaks, you want to know which of the two you are looking at.
What to verify before you pay
Git present on the server itself, with SSH available to drive it. A release routine that holds up: push to the remote, pull on the server, or let a hook do it. PHP and Node tooling installed for whatever build step runs once the code lands. Fast rollback, since deployment discipline is rollback discipline wearing another name.
Then the check that belongs to this brand: whether the account that holds the repository also holds the DNS. Deploying in one place and editing records in another is how a cutover ends up half-done.
You deploy to a hostname, not to a server
A request arrives carrying a hostname, and the hostname is what selects the document root your release landed in. That is why a release can be entirely correct and still not appear: the name may be pointing at a different root, or at a different server altogether.
It is also what lets you rehearse. Give the release a first-level hostname of its own, deploy there, and check it under a real certificate before the public name is involved. A wildcard covers *.example at one level, so a single-word label needs no certificate work of its own; nest it deeper and you have bought yourself an extra job.
The sequence that keeps the two apart
If the name is already pointing here, deploy freely — nothing in a pull touches a record. If you are moving in as well, do it in this order: drop the TTL to 300 seconds the day before, get the release deployed and verified against the new server directly, then repoint the record and let the short caches turn over.
Reverse that order and you have a new address serving code you have not checked, at the exact moment the caches are filling with it.
The plan behind it. In practice that means our Turbo option: a single rate that already includes SSL, the move, the copies and the mailboxes, and an upgrade you apply without a migration.
A free SSL certificate comes with every plan and reissues itself before the old one lapses — the padlock is never yours to diarise. Hosted somewhere else already? We move the whole site at no charge, usually within 24 hours, and it goes on answering visitors throughout.
Interest declared, then the advice
We sell both halves of this — the hosting and the registration — so the temptation is to tell you they are one purchase. They are not, and a page that pretends otherwise is the reason people cut over on a Friday.
Somewhere else at the moment? Our engineers move the whole site free, usually within 24 hours, and your current provider keeps serving visitors until you approve the copy.
- Repository and DNS in one login
- TTL editable before every cutover
- Certificates issued once the name resolves
- Rollback that does not wait on a cache
Why Hosting & Domains
Standard on every plan
Releases that do not touch records
A pull changes files and nothing else — the zone, the delegation and the certificate all stay exactly where they were.
A hostname to rehearse on
Deploy to a first-level label, check it under a real certificate, and only then let the public name see it.
Both jobs, one client area
The account holding your shell also holds A, AAAA, CNAME, MX and TXT — no switching suppliers halfway through a cutover.
One rate, published in the open
One figure for year one and every year after it, printed rather than footnoted.
A company you can look up
Azaanex Inc., federally incorporated in Canada — read the filing before you trust anyone with a name.
The verdict, turned into an order
This page's verdict, available to buy: the Turbo plan, one rate, the essentials already in it.
Prices Side by Side
How our prices sit against the majors
What the market typically charges to join and to renew, set beside ours, including the renewal figure most comparison charts leave out.
| Feature | Hosting & DomainsMost popular | Typical household-name host | Typical bargain host | Typical loss-leader deal |
|---|---|---|---|---|
| Starting price / mo* | $2.42/mo | $4–$6 | $2–$4 | $1–$3 |
| Renewal price / mo | $2.42/mo | $10–$15 | $8–$12 | $4–$6 |
| Entry-level plan renews at the price you signed up at | ||||
| SSL as standard | ||||
| Migration done for you | ||||
| NVMe drives on the entry-level tier | ||||
| Backups run every day from the first tier up | ||||
| Real humans on support, 24/7 |
*Our own column shows the lowest-priced annual plan on our books, pulled live from the same catalogue that feeds the pricing page, which is why it cannot go stale. Beside it sit three columns holding the ranges that hosts in each bracket tend to advertise: introductory rates that normally ask for one to four years up front, then climb once the term runs out. Naming rivals and printing their figures is something we gave up, since a price nobody can verify on the day you happen to read this has no business on the page. Measure us against the host you are actually weighing up, and give the renewal row the hardest look of the lot.
Quick Start
Order placed to site online
- 1
Separate the release from the cutover
Two changes, two days. The one you can revert instantly should never be tangled with the one you cannot.
- 2
Deploy to a label first
A first-level hostname, a real certificate, a full run-through. It costs nothing at the registry and answers within minutes.
- 3
Lower the TTL, then move the record
300 seconds the day before means a mistaken record is a five-minute problem rather than a day-long one.
Built In
Fitted to every plan
- Terminal access with Git and Composer on the developer tiers
- Every record editable by you, in the account you already hold
- SSL at no charge, renewed before the old certificate lapses
- Per-site PHP from the control panel, extensions on the same screen
- cPanel, with backups that restore onto any other cPanel host
- The renewal figure equal to the joining figure, in writing
- Mail delivered at the name on your registration
- Support staffed round the clock, with records inside the remit
- LiteSpeed caching built into the server rather than added by plugin
- Softaculous on the account for installing applications
Frequently Asked
Questions we field again and again
Should a release and a DNS change ever happen on the same day?
Preferably not. A release is reversible in seconds; a record you have just published sits in caches until their timers expire. Keeping them apart means that when something looks wrong you already know which system to look at, and the fix for one is never blocked by the other.
How do I check a release before the name points at it?
Two ways, both cheap. Deploy to a first-level hostname under a name you already hold, which is free at the registry and resolves within minutes. Or address the new server directly and send the correct hostname in the request, which exercises the same document root without any record changing at all.
Does a Git deployment touch my DNS records?
Not at all. A pull writes files inside a document root. Records live in the DNS panel and delegation lives at the registry, and neither is aware a deployment happened. If a site changes behaviour after a release, the cause is in the code or the document root, not in the zone.
Can one account hold several sites and their names?
From the Turbo tier upward, yes — several sites, each with its own name, mailboxes and certificate, inside one account. If the extra sites belong to clients rather than to you, look at reseller hosting instead: it keeps each one properly walled off, registrations included.
Keep reading
Business Hosting
Shared hosting with the full developer kit — SSH, Node.js, Python and PostgreSQL on one name.
Laravel Hosting
Laravel-ready hosting with Composer and Git releases, certificate issued as the name resolves.
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.
Deploy freely. Move records deliberately.
SSH and Git on the account, every DNS record in the same client area, and a renewal figure that stays where it was.
View Business Hosting plans