Web Hosting

Hosting that comes with someone responsible for it

Shared hosting is cheap until something breaks, and then the only path forward is a ticket form and a queue. The disk fills, a certificate expires over a weekend, an update lands badly — and the question stops being technical and becomes "who is actually looking at this?"

We host the sites we build, on infrastructure we manage. A problem has an owner from the first minute, and that owner has seen the site's code before.

Handled on our side

• TLS certificates issued and renewed automatically. No expired-certificate warnings in front of your visitors.
• Scheduled backups, with restores tested rather than assumed.
• Operating system and runtime updates applied on a maintenance schedule, with changes recorded.
• DNS records managed for you, on a domain that stays registered in your name.
• Monitoring for availability, disk headroom, certificate expiry and backup success.
• Mail alignment. If your email runs elsewhere, the MX, SPF and DKIM records are kept intact through every change.

Moving in without going offline

Migration from your current provider is part of the job, not an extra line on the invoice. It follows the same sequence every time, because the sequence is what keeps the site reachable.

1. Copy first. Files and database are copied to the new server while the old one keeps serving every visitor.
2. Test on a temporary address. The site is opened and clicked through on the new server before anything public changes.
3. Lower the DNS TTL. A record's time-to-live tells resolvers how long to cache it. Dropping it to around 300 seconds a day or two ahead of the switch means the change spreads in minutes instead of a day.
4. Final sync, then cut over. A last delta sync catches anything that changed during testing, and the DNS switch happens in a low-traffic window.
5. Keep the old host running. The previous server stays up for a few days afterwards, so visitors still holding a cached record land somewhere real.

This is a parallel-run migration, and it is the reason the public address never points at a half-finished copy. The alternative — tearing down the old site before the new one is proven — is where migration horror stories come from.

Shared, managed or your own server

Most business sites sit in the middle column. The move to your own server is usually driven by a requirement — a piece of software that needs root, a rule about where data lives, a workload that no longer shares well — rather than by traffic alone.

When we are not the right fit

• You want the cheapest possible hosting line on the invoice. Managed hosting costs more than a shared plan, and the difference is the work described above.
• You have an in-house team that already patches, monitors and restores. Paying twice for the same discipline makes no sense.
• Your application needs a platform we do not run. We will say so rather than force a bad fit.

What the monitoring actually watches

"Monitoring" on a hosting page usually means a ping test that notices when the site is already down. That is the least useful moment to find out. The checks that matter are the ones that fire before anyone notices anything.

• Disk headroom, not just disk failure. A filesystem at 95% is a site that will stop accepting uploads and a database that will stop writing — usually on the same afternoon.
• Certificate expiry, with weeks of warning. An expired certificate does not degrade the site, it replaces it with a full-screen browser warning.
• Backup completion, checked as an event rather than assumed from a schedule. A job that silently stopped running three weeks ago looks exactly like a job that is working.
• Response time trend, because a site does not usually go from fast to down. It goes from fast to slow to timing out, and the middle stage is where the fix is cheap.
• Memory pressure and process restarts, which are how an application tells you it is struggling before it gives up.

Each of these has a person attached to it. An alert nobody is responsible for is a log entry.

Security that is maintenance, not a product

Most site compromises are not sophisticated. They exploit an old version of something that has had a patch available for months, a password that was reused, or an admin interface left open to the whole internet. None of that is stopped by a badge in the footer.

What actually reduces the risk is dull and continuous: applying updates on a schedule, keeping the firewall closed to everything that does not need to be open, reviewing who still has access and removing the accounts of people who left, and keeping backups far enough away that an attacker who reaches the server cannot reach them too.

We do that work and record it, so "when was this last updated" has an answer rather than a guess.

Frequently asked questions