Skip to content

Technical Details

  • by

The Geeky Stuff

While we love to talk tech, we also host content that might draw malicious intent.  The more we disclose, the more someone with ill intent can infer about our platform and the possible ways to attack your site in an attempt to silence or embarrass you.

With that out of the way…


  • There is an art to tuning web servers to optimize performance.  We have been doing this for two decades now, and we’ve gotten pretty good at it.  The components in question are:
  • The web server itself: we have gotten good performance out of Apache and Nginx web servers for years, but the best performance available right now is on the Litespeed web server.  Tweaking can make Nginx close, but there are still some things like time to first byte that Litespeed handles really well.  More important for our clients: Nginx doesn’t support htaccess files, which will matter as you try and do more complex things with your site.  Litespeed is the clear choice right now.  The only disadvantage we’ve been able to find is the cost, as all of its competitors are free.
  • Caching: I could write about different approaches we’ve taken in the past and how one can optimize things, but it’s just a distraction.  We run Litespeed.  Litespeed offers LSCache.  Install LSCache for WordPress (or Drupal, Or Joomla, or WooCommerce) and enjoy great performance out of the box.  It’s that good.
  • Database tuning: this was critical a decade ago, but with enough memory and fast processor cores it matters a whole lot less.  In out case, we own our own servers, so we have….
  • Plenty of resources: we have RAM and processor resources to spare.  The server your site will live on is very over-provisioned.


Let’s talk a little more about resources.  Other hosting companies advertise SSD storage on their high-end plans, which is good, but we have what we believe is a better way.  Let’s start with an overview:

  • We store most of our bulk data on spinning hard drives.  This is configured in a way that we can multiply the performance of the drives and make drive failures a non-event, but it’s still a spinning hard drive that hosts most of our data.
  • We use a fast SSD as a cache for data that’s been accessed recently, or that’s on the most frequently accessed list.  If you’re likely to use it soon, it’s on an SSD, and that SSD is between 11 times and 150 times faster than a hard drive, depending on whether we’re looking at sustained read/write (like big images or videos) or IOPS (like database queries.)  This is what most other web hosts offer on their best plans.
  • Our storage server keeps a list of the most in-demand data and keeps it in memory and only writes to the SSD cache when no more of the cache can be stored in RAM.  This is for performance – while the SSD cache is ~ 120 times faster than the hard drive, the memory cache is closer to 100,000 times faster than the traditional hard drive.  This is a big improvement.
  • The web and database servers have the best understanding of which data is the most relevant for serving your web pages and doing your database lookups.  If enough memory is allocated to these servers, they will cache the data themselves, in memory.  Nothing is faster than this memory cache.
  • And we have plenty of memory on the server.  If we run out, we can assign more with a 3 minute reboot.  We try to allocate enough RAM so that everything necessary to serve your web pages is stored in memory.  Nothing is faster than this.


So when we say “fast storage” on all our plans, what we mean is “yes, we store some of your data on an SSD too, but the parts that affect your site’s speed are probably stored in RAM on one machine or another and you’ll see better performance on our platform than on another host that saves money on (expensive) RAM by deploying SSDs.”


As we stated above, this is hard to detail without compromising security.  A detailed listing here allows the guy trying to take your site down to build a good map of our network so he knows where to focus his efforts.  We don’t want that.

We also need to make this clear up-front: there is no such thing as perfect security, and anyone can be hacked if their adversary is willing to spend enough time and money to do soAnyone.  If you publish sexually compromising photos of top level officials in the Chinese Communist Party on your web site, and as a result the CCP mobilizes their hacker corps against our servers, we’re getting hacked.  That’s just the way things are.  (You may be likely to disappear soon too, but that problem is outside of the scope of this document.)

What we have done is follow standard security practices in the way we built our infrastructure, configured authentication, deployed our backups (both offline and off-site), and so on.  Choices of software were made with a hard look at security, and we practice security in depth as much as we can.

We believe we have done as much as is possible to secure your data, and to protect you from other clients who may be hosted on your server.  We have monitoring, scans, proactive processes running in the background, and third party security experts that look at questionable things.

We take security seriously.  But again, that only goes so far.  We make it easy to perform your own backups, and there are multiple third parties that you can employ to make regular, automated backups of your data.  We take backups very seriously, but we encourage you to assume we don’t.  Belt, and suspenders, and underwear just in case, and…


Our goal is 100% uptime.  We don’t meet it all the time, but we do most months.  Experience has taught us to have reasonable expectations here. 

Here is how most of the threats to uptime are handled:

  • When the power goes out, our UPS keeps the servers running.
  • If the power stays off for more than five minutes, we switch over to a generator.  We maintain enough fuel to keep things running for a week, and we test the generator monthly.
  • Our web hosting platform is virtualized.  This means that the virtual server running your web site thinks it’s a real server, and is independent of the actual physical hardware it runs on.  If the physical server hosting the virtual web host fails, another physical server will notice and restart the virtual web-host within 2 minutes.  When this happens the virtual server is coming up right about the time our text message outage alerts are coming through.
  • Networking hardware is redundant.  If a network card, cable, or switch fails everything keeps running without a hitch.
  • The hardware firewall is not redundant, but a spare is sitting next to it in the rack, with the current configuration installed on it.  “Failover” means moving the cables from one box to the second and booting it, and generally means about 3 minutes of down-time after our alarms go off.
  • The storage server is not redundant either, but we make snapshots frequently, and these are stored on a second storage server.  Failure of the main storage server means restoring from the most recent snapshot, or importing the snapshot as a new complete server.  This is generally a 30-90 minute outage, but we hope this never happens.  The closest we have seen to this in the last two decades is unexpected reboots, which are much less disruptive.  We plan for the worst, however.
  • Data comes into our network via fiber, buried underground.  It is possible someone with a backhoe will cut the fiber because he didn’t check with the utility company before cutting, and this would result in hours of downtime.  Unfortunately there is no way to mitigate this – we are in a rural area in the Southern United States, and a backup bandwidth provider would likely come over the same bit of fiber.  We could use satellite as a failover, but latency there makes that impractical.  This is a low probability failure, but it may happen.


We have taken the steps we can to offer great reliability.  We know what the weak points are, and have designed and documented procedures for recovering from problems.

Leave a Reply

Your email address will not be published. Required fields are marked *