I recently migrated my site’s backend, i.e. blog.souptik.dev to Hostinger. Just FYI previously it was on Pantheon, which you might know if you have read the blog – “This site runs free”.
Why I migrated, is a topic for the next blog, but in this blog, I will share the bittersweet experience of hosting with Hostinger. So, here we go.
Autopay – a facility for me or you?
The first thing you’ll notice when purchasing a Hostinger plan is their request for an autopay mandate, accompanied by the prompt: “This will make it easy for you to process the next payment.”
Seriously? Easy for me to process the next payment, or easy for you to secure it?
I understand that this practice is common in many other places, but I personally dislike being forced into setting up autopay, so I felt it was worth pointing out.
Super cool dashboard
Hostinger’s dashboard might look a little overwhelming at first look, but with time as you get more and more familiar, it will feel super cool. Some noteworthy points:
- Super easy Database access: It provides super easy Dabatase access through PHPMyAdmin. Just a click of a button auto logs in to the database. And from there I could super easily import the DB dump from my previous Pantheon site.
- Super easy Files access: Generally in other places, even in Pantheon you have to install an FTP client to connect to the server to access the files, but Hostinger provides you a super cool dashboard to access all your files, perform any operations, download, upload anything! Loved it! ❤️
- Tech tools Out-Of-The-Box: Hostinger comes equipped with engineering tools (the “premium” plan though) like SSH access and pre-installed WP-CLI right out of the box. For example, after importing my database, all I had to do was SSH into the server, navigate to my site, and run the search-replace command. Boom—done in no time!
- Easy account sharing: While it might not seem like a big deal, I really appreciated how seamless Hostinger makes account sharing, allowing multiple people to use the same plan.
Super confusing DNS management
Hostinger forces you to use their DNS nameservers, not your domain registrar’s. That means when you start using Hostinger you have to migrate all of your DNS records to the Hostinger’s nameserver, and kind of vendor-locking-in. 🙂
And the story doesn’t end there, their DNS management – oh my god! 🫠
They don’t have a single DNS register for storing all the domains. They have separate registers for each site. Let me explain with an example –
So, I have two sites souptik.dev and blog.souptik.dev. The first one is hosted on Vercel and the second one is what I was trying to host on Hostinger as a WordPress site.
Therefore I created a new site called blog.souptik.dev
and started to set up the DNS records. So, as per normal knowledge, I did put DNS records like this:
@
pointed toVercel's IP
blog
pointed toHostinger's IP
And then I waited and waited, and just read this line a thousand times.
Just to realize by blog.souptik.dev
was now pointing to Vercel (and obviously Vercel was rejecting it because it was expecting souptik.dev
).
And here comes the shocking part — this register, where I was entering the records is only maintained for blog.souptik.dev and its subdomain. So, as per the above records it is understood 🤦:
blog.souptik.dev
pointed toVercel's IP
blog.blog.souptik.dev
pointed toHostinger's IP
To fix this I had to modify these records:
@
pointed toHostinger's IP
Created another site with a domain souptik.dev
(this is one simple PHP site, as I will be not using the site, rather just entering the DNS). In that one added a DNS record:
@
pointed toVercel's IP
And that’s how it rolls. 🧩
Not-so-good deployment workflow
This was one of the most frustrating aspects of the entire process for me! 😟 Admittedly, this might be a bit opinionated, but here’s my take.
Typically, I prefer a deployment process that many hosting providers like Pantheon or WordPress VIP offer. These providers maintain a private Git repository of their own, and all we need to do is push changes to that repository. The repository is private and managed by the provider and therefore we have the whole WordPress codebase in that, including wp-config
file containing secrets.
In this setup, we usually maintain our own Git repository containing all the package manager files like package.json
, composer.json
along with our code, so that we don’t have to bloat our repositories with all the packages/plugins and the build files. We then establish a workflow to install dependencies, build files, and push only the necessary items to the provider’s repository. It’s a clean and efficient workflow and here is something you can take a look at to understand this workflow.
But Hostinger says – “you give me a Git repository and a branch from where I will clone the contents (do a composer install if composer.json
file is present) and dump the contents to a folder also specified by you (the destination folder should be empty BTW)”.
Now I have a few plugins (one of them custom) and a custom theme to deploy. Just FYI – I typically manage all plugins and themes through Composer and deploy them that way, avoiding the WordPress dashboard to simplify migration.
But given the restrictions mentioned earlier, how am I supposed to deploy them? I need to upload the plugins
and themes
folders to the wp-content
directory—but that directory must be empty. How can I make wp-content
folder empty!?🫠
And here comes my hacky solution:
- I created a workflow to install/build stuff and push it to a new branch. I am only pushing the plugins and themes though, to keep it clear. Here is the code which does that and here is the branch which is created and updated through the workflow.
- Now I deploy this branch to a custom folder in Hostinger named anything (
git-deployment
). And then symlink them to thewp-content
‘s plugins and themes directories, something like this:
And that’s how it rolls. 🧩😅
Conclusion
In my opinion, Hostinger is an excellent choice for anyone looking to build WordPress sites from a non-technical perspective. If your goal is simply to create websites, install third-party plugins and themes, and design beautiful sites, Hostinger is hard to beat—especially given its competitive pricing. It’s my go-to choice in such cases!
However, from an engineering perspective, where custom plugins, themes, auto-deployments, and other advanced configurations are involved, you might face a few curve-balls. While Hostinger does provide all the essential technical features like SSH access, FTP access, and database access via PHPMyAdmin, there are some architectural limitations, particularly in how it handles auto-deployments and similar advanced workflows.
That said, considering how affordable it is, the value you’re getting is exceptional. Personally, I’m quite satisfied with my purchase!
How was the blog?