I have five TLS certificates expiring on five different dates between 26 October and 6 December 2026, issued by two different authorities, on three different kinds of hosting. That is the honest shape of a one-person web business. It is not a growth chart. It is a calendar of small things that expire, spread across more control panels than any sensible person would choose on purpose.
This is the operations half of running mine. The commercial half, scoping and pricing the work, is a separate problem and I wrote about it in what actually changes when a one-person web studio starts using AI. Here: what is running, where it lives, what it costs once the introductory price ends, what I measured on all of it on 20 September 2026, and the jobs I refuse to hand to any tool. Everything below is a site I own. I do not publish anything about work I do for other people.
What is actually running, and where
Five properties, on three kinds of hosting. Three of them live on one shared-hosting plan.
| Site | Where it lives | What it is | Certificate expires |
|---|---|---|---|
| vireltify.com (this site) | Hostinger shared | WordPress, PHP 8.3.33 on LiteSpeed | 26 Oct 2026 (Let’s Encrypt) |
| My hosting review blog | Hostinger shared, same plan | WordPress, same stack | 6 Dec 2026 (Let’s Encrypt) |
| creativowebvlc.com | Hostinger shared, served through Hostinger’s own CDN | My studio site, small and static in practice | 30 Oct 2026 (Let’s Encrypt) |
| A small SaaS side project of mine | Hostinger VPS, KVM 1 | Node and Express behind Caddy, managed by systemd | 21 Nov 2026 (Let’s Encrypt) |
| ahorrosolarlevante.com | Cloudflare Pages, free plan | Static HTML, deployed from a repository | 2 Nov 2026 (Google Trust Services, issued by Cloudflare) |
Netlify sits outside that table because I only use it for throwaway demos, and the domains are split between IONOS and DonDominio for no better reason than that is where I happened to register each one. Nobody designs this. It accumulates. Every time you pick the obviously correct host for one particular job, you add a panel, a billing date and a deploy mechanism to remember.
The one decision I would defend is putting the purely static site on Cloudflare Pages and leaving WordPress on shared hosting. A static site has no database to back up, no plugin to update and no PHP version to worry about, and the free plan covers 500 builds a month, 20,000 files per site and 100 custom domains, with the documentation stating plainly that requests to static assets are free and unlimited and that there is no charge for egress or bandwidth (Cloudflare Pages limits, checked 20 September 2026). For a site that changes twice a year, that is the entire operational burden gone.
The VPS is the only thing that can wake me up, and it cannot
Shared hosting fails quietly and somebody else fixes it. A VPS is mine. On the KVM 1 box I run a small Node application under systemd with Caddy in front of it, which means I own the process supervision, the reverse proxy and the certificates.
Caddy requests and renews the Let’s Encrypt certificate automatically, which is the best part of the setup right up until the moment it does not work. That certificate has been the single most annoying thing about running the machine. Here is the part worth being precise about, because it is the real lesson and not the exciting one: every time something has gone wrong there, I found out by opening the site in a browser. I have no uptime monitor, no alerting and no log shipping. If that VPS stops serving at three in the morning, nothing tells me.
I am not going to dress that up as a considered trade-off. It is a gap, and I would rather say so than write a monitoring section describing a setup I do not have.
What it costs, with the entry price and the renewal kept apart
Hosting pricing is built to be quoted wrong. The headline number usually requires paying three or four years up front and then multiplies at renewal. Here are the two plans I pay for, plus the ones I have looked at, with both numbers and the date I checked them.
| Plan | Entry price | Renewal | Commitment |
|---|---|---|---|
| Hostinger shared, Premium | $2.99/month | $10.99/month | 48-month term paid up front |
| Hostinger shared, Unlimited | $3.99/month | $16.99/month | 48-month term, adds daily backups |
| Hostinger VPS, KVM 1 | $6.49/month | $11.99/month | 24-month term paid up front |
| Cloudflare Pages, Free | $0 | $0 | None |
| Netlify, Free | $0 (300 credits) | $0 | Personal plan is $9/month for 1,000 credits |
| IONOS Essential (US site) | $4/month, first year | $8/month | 1-year contract |
| DonDominio Básico | 39 EUR/year, VAT excluded | Not published on the page | Not published on the page |
Sources, all checked on 20 September 2026: Hostinger shared hosting, Hostinger VPS, Netlify pricing, IONOS web hosting and DonDominio hosting. I opened the European pages from Spain, so currency and in some cases the figures depend on where you load them. The Hostinger shared entry price is about 3.7 times below its renewal, and getting it means paying four years up front. That is how the market works, but a monthly cost written down without the renewal beside it will be wrong within a year.
One thing worth flagging if you are about to put ads on something: Vercel’s own FAQ states that the Hobby plan is for personal, non-commercial use (Vercel pricing, checked 20 September 2026). A blog carrying advertising is not obviously personal and non-commercial. I have never used Vercel, so I cannot tell you how they read that in practice, only that the sentence is there and worth reading before you build on it.
The measurement I run, and the four things it does not prove
On 20 September 2026 I ran a small curl script against all five properties from my home fibre connection in Valencia, Spain: five requests per site, roughly two seconds apart, in two modes. One fetched the URL as a visitor would, the other added a cache-busting query string. I recorded DNS, connect, TLS and time to first byte, and I publish the median with the minimum and maximum.
- The WordPress blog on shared hosting: median TTFB 0.46 s, range 0.38 s to 0.90 s, 100,574 bytes of HTML compressed to 26,886 with Brotli.
- This site, same plan and same stack: median TTFB 0.57 s, but a range of 0.53 s to 1.50 s. Nearly a factor of three between the fastest and the slowest of five consecutive requests.
- The Node app on the VPS: median TTFB 0.30 s, serving 1,531 bytes of HTML.
- The static site on Cloudflare Pages: median TTFB 0.28 s, served from the Madrid edge location, 13,736 bytes of HTML.
Now the disclaimers, which are longer than the results and should be. Five requests in a minute are not a benchmark. I measured a route, Spain to a server, not a provider: my ISP, peering and the chosen edge location are all inside those numbers, and a reader in Ohio would get different ones. I only fetched the HTML of each home page, with no CSS, JavaScript, images or field data, so none of this says anything about page speed or Core Web Vitals. And the sites are not comparable to each other: a 100 KB WordPress home page and a 1.5 KB Express response are different work, so the static site being quicker proves nothing about the hosting underneath it.
The most useful number there is the ugly one. A spread from 0.53 to 1.50 seconds across five consecutive requests to the same URL is what shared hosting looks like when you watch it, and it is the figure I would want if I were reading this instead of writing it.
Two gaps that ten minutes of measuring found in my own setup
I did not run this expecting to learn anything about my own sites. I learned two things.
First, not one of the five sends a Strict-Transport-Security header. HTTPS works everywhere, HTTP redirects to it everywhere, and no browser is told to remember that. It is not a catastrophe and it is not the hosting’s doing. It is something I never configured, on any of the five.
Second, neither WordPress blog returned any page-cache header at all. Every request goes through PHP. The tell is that the cache-busting URL came back as fast or faster than the plain one, the opposite of what you see when a page cache is working. To be careful about what that means: it is a reading of two home pages on one day, and it says these two installations have no caching plugin doing anything, not that the host does not cache. Fixing it is a plugin and an afternoon. I go through what else is installed on those two blogs in the publishing stack I actually run on my own two blogs.
The routine that is identical everywhere, and the part that never is
The only way I keep five properties from rotting is that the post-launch routine is the same on all of them regardless of platform: submit the sitemap to Search Console with its complete address, clear out any stale sitemap left from a previous version of the site, resubmit after significant changes, request indexing for the pages that changed, and check that robots.txt is not quietly blocking something. If the site carries advertising, ads.txt gets checked in the same pass. I wrote that out step by step in the Search Console checklist I run after every launch, and it is the single highest-value habit in this whole post.
What is never the same is how a change gets from my machine to production. Cloudflare Pages builds from a push. Netlify takes a drag-and-drop bundle, and on Windows that bundle has to be built with tar rather than the PowerShell archive command, whose zip breaks stylesheet paths once deployed. It broke a deploy once, and now it is a line in the rules file my assistant reads before every session. WordPress is the editor, or the REST API for anything repetitive across many posts. The VPS is a file copy over SSH, a systemd restart and watching the log.
Four deploy mechanisms is three too many. Consolidating them is the kind of improvement that never gets prioritised, because nothing is currently broken.
What I will not hand to a tool
AI does a large share of the building here. Almost all the code on these sites starts as something I generated and then argued with, and I use it for bulk edits I would never do by hand, such as reshaping a hundred posts through the WordPress REST API. That workflow is in my notes on the coding assistants I use every day and the ones I have only read about, and on where the model earns its subscription in my review of Claude after building my own sites with it.
The list of what stays manual on the operations side is short. The rest, legal text and anything that claims I used a product, is in the Claude review linked above.
- Credentials and control panels. Nothing automated logs into hosting, DNS, Search Console or a payment account on my behalf.
- DNS changes. They are fast to make, slow to propagate and capable of taking a site off the internet for a day. I make them one at a time and I read them twice.
- Reviewing generated code before it goes near the VPS. Shared hosting limits the damage. A box I administer does not.
If you are about to go from one site to four
Three things I would do differently, in order.
Keep the expiry dates in one place: domains, certificates, hosting terms and anything on an annual contract, with the renewal price next to the entry price. My five certificate dates renew automatically and I still had to go and look them up to write this post, which tells you how well I would cope if one of them stopped.
Put anything that does not need a database on a static host on day one. Moving it later is a migration; starting there is a choice that costs nothing.
And make one real backup, by hand, that does not depend on the panel holding the site. The only backup of this blog I can point to is the full export I pulled through the REST API in September 2026, while preparing the rewrite this article is part of. Everything else is a checkbox in a control panel that I have never once tested by restoring from it. That is not a system, it is an assumption, and I am writing it down here so it stops being one.