The Pure Blog | Page 4 of 10 | Pure Energy Systems
21 Jan 2019

2018: A Year In Review

At the start of 2018, in a rather sparse and simple blog update we laid out some pretty ambitious, if vague, plans for the year.  I’d like to take a moment to reflect on what we got done in 2018, and some ideas of where we’re looking to go in 2019…


All in all it was a pretty productive year.  But we’re not going to just sit back and rest on our laurels.  Once the current Server Migration Project is complete (blog post coming), we’re looking at the following items as possibilities for 2019:

  • Increasing Resource Limits for all of our Shared Linux Hosting Plans.
  • Unveiling additional new products and services based on client and market demand


All in all, I believe 2018 was a great year overall, many of the things we set out to accomplish this year were completed, and we’re in a position to not only finish out the few remaining tasks from 2018, but also to start looking toward the future in new and exciting ways.

03 Jan 2019

Domain TLD Promotions go live!

Today we’ve enabled domain registration promotions, the results of which you can see on the big list of domain TLDs that are available for registration, where there are currently around 65 TLDs running with special “On Sale” promotional pricing.

TLD promotions occur when a given TLD registrar offers a special promotional price on new registrations for a given TLD.  Sometimes these discounts can be rather large (for instance, .accountants domains are normally $91.44/year, but right now can be had for $11.48 for the first year).


  • Sweet low pricing for that first year registration


  • Terms of the promotion are dictated by the TLD.   We don’t control how long the price is good for, or when they expire.   When a TLD promo expires, our pricing will revert back to the normal price automatically.  Some promotions may only last a couple weeks, whereas others can run for months.
  • They usually only apply to 1 year, new registrations.  We hardly ever see promotions on transfers or renewals.
  • As a result, at the end of that first year, you’re looking at a regularly price renewal.

In keeping with our previously stated thoughts on domain pricing, we use the same markup process for promotional pricing that we do for regular price domains.  So the greater the discount the TLD is offering, the lower the price we can offer to you.

In an effort to be as transparent as possible about the eventual renewal costs, if you add a domain that is on promotion to your cart, it’ll show up like this:

example of how promo domain registration pricing is reflected in the cart

We’ll show you both the currently promotional registration price you’ll pay today for the 1st year registration, as well as the current 1 year renewal price, with the goal being to minimize any potential surprises down the road. (Obviously the TLD could raise their price between now and then, but we wanted to at-least show the current renewal pricing, as we don’t know exactly where their pricing may be in 12 months).

22 Dec 2018

New SSL Certificate Offerings

Earlier this year we were very happy to announce that we were going to be able to start offering Free Domain Validated SSL Certificates to all our our hosting clients, backed by COMODO CA and issued by cPanel.

Thanks to the integration with cPanel, clients would be able to gain this benefit with zero work on their part.  cPanel would handle the issuing of the certs, provisioning them into the hosting account, and even handle renewing them every 90 days as they came up on their expiration dates.  It was truly “zero hassle SSL”.

Given the state of the web in 2018, and the growing trend towards “https everywhere”, we were very excited to be able to provide this much needed service free of charge to all of our clients for use with their Pure Energy hosted websites.

The introduction of AutoSSL to our feature lineup has helped to shine a light on the topic of SSL Certificates for our customers, and this has led to a number of questions regarding SSL certificates, their usage, and the limitations of the AutoSSL feature:

  • How can I get a “Green Bar” SSL Certificate?
  • Can I get a “Secure Site Seal” for use on my site?
  • I need a certificate for <X>, and it’s not actually my site that’s hosted with Pure Energy.
  • Whats with this 90 day expiration thing?


Previously, when these questions would come up, we would generally point the person towards either RapidSSL, or GeoTrust, depending on what exactly they were looking for.    They would have to procure the certificate directly from the CA, and then, if they wanted to use the cert with their Pure Energy hosted site, venture back thru the gamut of “SSL Cert installation” via cPanel.  Now, to be fair, cPanel does a great job at making this as painless as possible, but even with cPanel’s help, SSL Installation can still be a bit…  cumbersome at times.

So, starting today I’m happy to announce that in addition to the AutoSSL feature, which is still included free of charge for every one of our hosting clients, we’re also going to be offering the following standard SSL Certificates for purchase via our Client Portal:


Pricing across the board is far lower than the rates that RapidSSL and GeoTrust charge directly, with certificates ranging from $17.95 for a 1 year RapidSSL Certificate to $279 for a 1 year GeoTrust QuickSSL Premium Wildcard.  2 year certificates are also available, generally at about a 15% discount over (2) 1 year certificates.

These certificates, while they are not included free of charge with your account, will have the standard 1 or 2 year renewal term (your choice), can be used on sites/services/things other than the site you have hosted with us, and will come with all the standard features/warranties/site seals that RapidSSL and GeoTrust offer with said certificate.

If you are a Pure Energy Systems hosting client, and you order a certificate via your Client Portal account for a website domain that you host with us, the portal can even handle provisioning the certificate into your cPanel account once the order is complete and the certificate authority issues the certificate.

It’s really a combination of best of both worlds, and we’re hoping that between “Free AutoSSL” and “Paid Certificates”, we can help do our part to make “https everywhere” as painless and cost effective as possible.



05 Nov 2018

Upcoming Server Transfers

In just a couple weeks we’re going to schedule some maintenance windows in order to migrate client accounts around to facilitate some server replacements.  Now, I know what you’re thinking:

“Didn’t we just do this four years ago?  Wasn’t moving to the cloud supposed to do away with these hardware refresh cycles?”

It’s true that virtualization and “the cloud” has empowered services such as ours in ways never dreamed off in the days of “a physical server for every need”, but there are a couple caveats and things to watch out for, including two forces that have come into play in our situation:

The Cloud Is Still Built On Actual Hardware

While it’s true that we no longer have to directly touch hardware, our infrastructure is still ultimately tied to physical hardware.  That hardware exists somewhere, and someone has to feed it, care for it, and eventually replace it.  The continual commoditization of PC server level hardware means that the newer stuff is generally faster and cheaper than the stuff from a few years ago.  This leads our providers into interesting situations where they end up wanting to encourage people towards the newer hardware, so they can decommission the older systems.

This is currently happening with us.  A couple months ago I took a phone call that started something like this:

“How’d you like 33% more RAM, 66% more Storage space, and faster, newer generation CPUs, at the very same prices you pay today?”

Now, I’m no fool, so I asked what the catch was.  And I learned: we’d have to migrate our existing servers to their new hardware infrastructure.  The new hardware is in the same data-centers and has all the same connectivity as our existing hardware, but we’d have to migrate over in order to enjoy the additional resources.   Thankfully they offer a “single click” button migration that would take care of everything for us, we just hit the button for a given server, it goes offline, transfers to the new hardware, and spins back up…  about 3 hours later.

Okay, not really the best option in the world, but something for us to consider.  After all, more resources are always a good thing,  we always like getting additional resources for the same price, that means we get to inject more resources into everyone’s hosting plans!  But.. a roughly 3 hour downtime for each server?  That’s kind of a big chunk for us to commit to, even for a significant resource increase, alone.

But there is another aspect to consider…

The Lingering Operating System

Believe it or not, in the last 8 months I have personally laid eyes on a production Red Hat Enterprise Linux 3 server, being used in a very critical and production oriented way at a customer site.  For anyone who doesn’t know, RHEL3 was released in 2004, the last released update was in 2007, and the entire release was announced as End of Life in late 2010, over eight years ago.  The machine in question was stood up circa 2006.  It’s twelve years old, and while it’s a security vulnerability nightmare, it lives on today in all of its 32bit glory.

Why?  Because it’s never needed to be rebuilt.  The company in question was an early adopter of server virtualization.  This rickety old machine was one of their first virtual systems, and it has persisted, and ran proudly, on numerous stacks of underlying hardware over it’s 12 year lifespan.  Virtualization and the flexibility it has brought us has minimized the number of situations that used to lead to a server getting rebuilt from the ground up.  While this is great for uptime and SysAdmin sanity, the dark lining is that it sometimes allows old machines to persist longer than they probably should have.

This story isn’t that unique, we’ve seen countless instances of “It’s still running, so we left it be” over the years, and we’re even guilty of it ourselves.  While we moved to CentOS 7 as our platform of choice shortly after the release CentOS 7.1, we’ve still got a fair amount of CentOS6 still running in our environment today.  While CentOS6 is not scheduled for a full “End of Life” until the end of 2020, we want to get ahead of the curve.


So with the these two datapoints lodged in our minds, we started thinking about the benefits of ‘refreshing’ our existing servers.  We built a list of possible benefits:

  • More resources, same cost.
  • Move everything to a newer Operating System.
  • Additionally, we want to move from the basic CentOS platform over to CloudLinux.  CloudLinux adds in a bunch of features and abilities that will benefit us in terms of server stability and management.
  • Look at retooling our systems to utilize PHP-FPM instead of SuPHP.  (Again, increasing performance for clients!)


And then we looked at the downsides of performance such a “full refresh” and weighed out the options before us:

Do Nothing

  • — No resource upgrade
  • — CentOS6 continues to live on, with a necessary replacement in the next 24 months.
  • +++ Zero work on our part.

Migrate, but don’t “refresh”

  • +++ Resource Upgrade!
  • — CentOS6 continues to live on, replacement still necessary within 24 months.
  • — 3 hour downtime per server
  • -+- Schedule downtime, “push one button” migration process

Build New Servers and Migrate Clients

  • +++ Resource Upgrade!
  • +++ Operating System Upgrade!
  • +++ Much less downtime per client!
  • — Most amount of work required on our part.


So, looking over the three possibilities, it became clear that, well, it makes sense to invest the work and do things right now. (Sorry team!)   Our plan is rather simple:

  1. Build out a new server, in the new hardware environment.
  2. Install everything, get it configured the way we like, test everything out.
  3. Schedule a window to migrate all customers from one “old” server over to the new one.
  4. Repeat steps 1-3 for each server that is getting a refresh.

Now, the only part of this that is impactful to our clients is step (3).    We’ll do all our normal tricks to minimize the downtime (lowering DNS TTLs, etc), but we can’t make the downtime go away entirely.  What we can (and will) do is transfer accounts one at a time, so instead of your website being offline for 3 hours, it will be down for a period of time measured in minutes, based on the size of your individual account.  (We usually lower DNS TTLs to 10 minutes, and most accounts transfer within that period of time).

A few points of interest:

  • We’ll be emailing all the clients on each server in advance of their maintenance window.  Generally we aim for a 5-7 day heads up for something like this.
  • Server names and IPs will be changing.   For cPanel clients who host their DNS with us (your domain is pointed to and, no action will be required on your part in order for your site to perform normally after the migration.  If however you have something out there hard-coded to a specific server IP address, you will need to adjust some things.
  • New server names and IPs will be included in the announcement emails that go out to clients on a server before it is relocated.
  • When your account is relocated, your account information in our portal will be updated at the same time.  So if in doubt, you can always use the links within our client portal to access your cPanel interface.


Our aim is to begin the migrations in the next 10-14 days, and to have the entire project wrapped up before the end of the year.

21 Sep 2018
19 Sep 2018

Changes to our billing system

Today I’m here to announce that we’re going to be sun-setting our existing credit card processing system via 2Checkout and have integrated our platform with Stripe to handle our billing needs going forward. This is something we’ve been looking forward to and working towards for some time, but since we’re talking about payment processing, the handling of credit card information, and a core business process for us, I wanted to take a moment and talk a bit about the why, the benefits, and the security aspects of this change.

First of all, this move is in no way a poor reflection on 2Checkout or the service they’ve provided over the years. We’ve been happy 2CO customers since our earliest days. Over the years we’ve had the normal ups and downs of any business relationship, but they’ve always done right by us in the end. When Stripe first came out on the credit card processing scene, their rates were a good bit lower than what we were paying 2CO at the time, and the integration options with Stripe, well, they blew us away to be honest. But that old custom home-brewed management platform that we only just recently moved off of? It would have needed quite a bit of work in order to move our processes from 2CO to Stripe. Work that, at the time, we weren’t willing to commit to on a platform we didn’t have faith would be the long term future for us. So we reached out to 2CO and expressed our concerns over the pricing gap versus Stripe. They were willing to adjust our pricing to match what Stripe offered and we back-burner-ed worrying about billing again for a while.

But even with the new pricing, we really wanted the flexibility of the Stripe API and what it could do for us.

With 2CO, you would place your order with us, and then be passed over to 2CO’s site to enter your credit card information. This meant re-entering things such as your name, address, etc a second time, and when the process was finished our system would be notified that a billing order was created (much like a PayPal subscription).

However, much like a PayPal subscription, once created, a billing order can not be altered in anyway. If your account, start a second account, order a domain, change your hosting plan, have a monthly bandwidth overage, or anything else of that sort, a whole new billing order is required. This was always a pain point for us. Customers with multiple accounts would end up with multiple billing dates each month, and every upgrade/downgrade would require a very manual process to get everything straight. Not only was this extra work for us, but it was overly complicated from the client’s perspective as well.

In short, in the interest of credit card security (and PCI compliance!) there was a very hard and fast border between the data we could see/touch/change, and things that required 2CO to change things on their end (or be performed manually via their site), and so the integration options available to us, and thus, to our clients, via the client portal, were very limited.

Even something as simple as updating the card on file for an order (if say, your card expired), we could provide a link to the 2CO site, but you would need to provide the billing order number, plus other pieces of identifying information (last 4 digits, billing zip code, etc) to confirm your identity with 2CO. There was no authenticated way for us to say “This is Bob, please let Bob update his card that you have on file!”.

With Stripe however, we get flexibility in all these things. When you enter your card info on our check out page, it is handed off to Stripe’s API, and what they return to us, and what we store on file for your account, is a unique identifier. That identifier lets us make subsequent API calls to Stripe later, to then take other actions related to that card without needing to know the full card information, and without us having to store the full credit card number/etc on our systems.

In short, armed with our own API keys, and a previously generated for us by Stripe token, we can do things like allow clients to update their own credit card on file directly via the client portal. We can do things likes upgrades, downgrades, services additions, etc all automatically and without a convoluted process requiring multiple steps on both your end and ours. We can even work towards every customer having a single monthly invoice and billing date (and thus, payment!), doing away with our multiple-account clients from being bombarded with various charges scattered throughout the month!

In short, life can be glorious.

Now, to get to this promised land of billing simplicity, we’re not willing to up-end everyone’s day. We’ve simply added Stripe based Credit Card processing to our ordering platform, and disabled the 2Checkout based option for new orders. PayPal remains untouched for those folks who prefer it.

New clients will have all their credit card billing handed via Stripe going forward.

For existing clients, if you currently pay for your hosting via 2Checkout, that won’t immediately change. If something comes up that would require a new 2Checkout order to be started (for instance, if you sign up for a new account, or upgrade your existing plan), that will be done via Stripe instead. Our billing team will help guide you through the process as needed, but by and large the process is going to be “log into the client portal, click to update your credit card on file, and you are done”.

The goal is that over time we’ll gain the benefits and flexibility of Stripe, without disrupting operations or requiring all clients to rush to the portal and enter their card information before their next billing date. We’ll monitor the gradual migration to Stripe, and may revisit the topic at some point if there’s some compelling reason to accelerate the process, but for now, this gets us on the path to a better place.

16 Sep 2018

Simplifying our plans…

I stumbled across something the other day that kind of made me giggle, it was a piece of marketing copy that we were using in the spring of 2002 to advertise our newly released to the public services.  Within the copy was an overview of our “Linux Bronze” Plan…

Linux Bronze Plan – $5.95/month
– 100 Megs Storage
– 3 GB Transfer
– 5 SubDomains
– 20 Email Accounts
– 5 FTP accounts
– 5 mySQL Databases
– 1 Mailman Mailing List

Now, our pricing hasn’t changed, and our plan names haven’t gotten any more imaginative, but our plans themselves, they’ve grown of the years  (And honestly, they’re about to do so again, but there is another project we need to finish before we can talk about that, so I’ll leave that for another update) as technology has continued to improve and costs have gone down.

To put things in perspective, at the time we launched this service, our original shared hosting servers were, if I recall properly, Pentium3 (600mhz or thereabouts?  single core) boxes sporting a lofty 1GB of RAM and if I recall, 40GB drives.

So at the time, storage and transfer, while important, were not the only resources we needed to balance and manage.  Adding a subdomain to a website?  There was a few kilobytes of RAM there.  Email accounts?  A few kb more for each of those.  So our plans also established a limit of things such as that, as shown in the list above.  And over the years, those quotas have increased as well, but to be honest, they’re really only there today because of a very deep seated dislike of the term “unlimited” around here.  Early on we watched so many “Unlimited <X>!” hosting firms crash and burn that it left a very bitter taste in our mouths for the word.  So much so that I simply refuse to tick the ‘Unlimited FTP accounts’ button in cPanel.

It’s not just the tainted history of the word, there are a very real, tangible issue that comes to mind.  The rule here is “If we offer something, we have to be able to actually provide it”.  So if we say “Unlimited Email Accounts!” it needs to be doable, in real, unlimited form.  Now, the fact is, if there was no quota on email accounts, and someone were to script a “log into cpanel and create random email accounts for my site” routine, it would eventually crash, and it might even impact performance for other people on the server.   Sure, it’d probably hit a couple million mailboxes before a problem occurred, and I cant think of a reason anyone would do it to other than to see if they could, but eventually a process would run out of RAM, or inodes, or.. something, and the server, along with all the other clients on it, would suffer.

Offering anything in “unlimited” form just doesn’t work when actually put to the test.

But at the same time, it’s now 2018, and defining account plans by the number of domains or email accounts just feels… dated.

So we’re not going to do it anymore.

Going forward, all of our shared hosting linux plans are purely built around the amount of Disk Space and Data Transfer.    Nothing else.   Now, this does not mean “unlimited” domains, email accounts, etc.  There’s still a limit built into all of our plans for these things.  It’s just…  well, it’s set high enough that we don’t think anyone is actually going to encounter, or probably even get close to, the limit.  And if you do start to find yourself getting close, open a support ticket, and we’ll look at the situation and see what we can do to accommodate your needs.

I’m internally calling it  “reasonable limits”.  In my mind it’s a bit of “if you use them for any reasonable use, you’ll be fine” and a bit of “if you come up with a way to use them that we didn’t think of, we’ll reasonably review the situation with you”.

But whatever we call it internally, externally, it means our plans just got a lot simpler.

14 Aug 2018

All TLDs Now Live

Every TLD that is available to us for domain registrations that we have decided to offer up is now available in the system. With a standing count of right around 400 TLDs, there is something for everyone. Maybe a little too many, as we now need to figure out a way to redesign our Domain Registration Page, as it’s a bit.. cumbersome as things currently stand. :/

(c) 2020 Pure Energy Systems LLC - All rights reserved.

back to top