|<<>>|1 of 91 Show listMobile Mode

earthli.com moves to HostFactory

Published by marco on

After 16 years hosted at Encodo Systems, earthli has moved from an Ubuntu VM to Web Hosting at HostFactory.

The move went very smoothly, although there are always a bunch of things to remember, especially when you haven’t changed servers for a long time—and especially when changing from a dedicated VM/server to shared web hosting. Thankfully, web hosting is a great fit for earthli because a dedicated server is quite expensive, starting at about CHF35.-/month. I took a look at cloud-based solutions and they very quickly rose into the same ballpark.

Features

Hostfactory offers:

  • Apache/PHP (7.3/8.x)
  • Unlimited MySql/Maria databases (I only need two)
  • 50GB of storage space (does not include database or Git repository space)
  • Unlimited Git repositories
  • 20 domain accounts (I only need one)
  • Unlimited traffic
  • Integrated SSL (LetsEncrypt)
  • SSH access (so I’d have scp for upload/download and shell access for stuff like mysql or moving files)
  • Unlimited Emails (probably don’t need this, as I’m running earhtli.com mail through Protonmail)
  • Backups
  • 30-day free testing (I’m all set up and haven’t signed up yet…)
  • Excellent and very responsive support. I’ve gotten answers within minutes and even got an answer on a Sunday.

Requirements

What does earthli.com need?

  • PHP 7.2 or higher (that’s the version I’d tested; I’m on 7.3 now, will probably migrate to 8.0 soon)
  • Modules:
    • EXIF
    • GD
    • Mysqli
    • Zip
    Git repos to store the earthli-webcore and earthli.com repos for easy deployment
  • MySQL databases (two of them)
  • At least 10GB of storage
  • .htaccess support (for securing folders)

Anything missing?

What has changed?

  • data.earthli.com[1] is no longer available. Use www.earthli.com/data instead
  • dev.earthli.com[2] is no longer available. Use www.earthli.com instead.

Drawbacks?

Are there any drawbacks to HostFactory? No, not really.

Getting used to a hosted environment was a good learning experience. I no longer have full control of the server, but I also no longer have full responsibility for setting everything up in a secure manner. PHP is set up to run more efficiently, with caching, and with maximal security (using Fast-CGI now instead of Apache modules). I have control over most PHP settings I need, but had to contact support to have them set my include_path for me.

They do a great job of that, including a WAF (Web Application Firewall), which has some pretty aggressive rules. For example, I tried to post an update to an article that had the word “sexual” in it and was rejected. I contacted support and was told about an IP-white-listing feature. After white-listing myself, it worked immediately.

This is fine, but I worried about how well the solution scales. After a quick discussion with support, it turns out that the (non-security-relevant) rules can be individually tuned, should that be necessary. I don’t think it’s necessary yet, but it’s good to know that it’s an option if IP-white-listing proves to be insufficient for my needs.

So far, so good! 👍


[1] I could have added the sub-domain at HostFactory and added a Rewrite rule to redirect to the new location. I didn’t do that because I’m not really interested in people continuing to use that sub-domain to access data.
[2] I’m no longer maintaining a separate “dev” instance online. I used to do this because it was one of the only ways to test that a newer version was actually working as expected on the same version as is running on the server. However, now that I’m using Docker for local development, I’ve got the same environment locally as on the server, so there are no surprises anymore. If there were to be a surprise, then I could easily roll back the change because I use Git for all deployment.