Atomic Beta Release for 4/5/2018. New User SignUp and SSH key management.

We set an aggressive schedule for new product/features in 2018. We fell a bit behind this month as we actually re-prioritized and added a few new items into the queue – however – always be shipping.

RELEASE NOTES FOR 2018.4.5

  • New user signup has been added to the new Atomic app.
  • The beta version of SSH Key management is add to new Atomic app.
  • SSL Certs will now auto-activate when linked
  • Improvements have been made to the Two-Factor Auth setup with a fallback in case the QR code does not load.

The primary feature we prioritized in this cycle was our new user signup flow and supporting backend automation. This new app component hooks into our new provisioning tooling on the DevOps side – the net result being faster VPS spin-ups for new customers. Typical handoff to the customer is now within just an hour or 2. We carefully verify each and every customer VPS as we provision it – our tooling has further automated some of the menial tasks but we still keep human eyes on the process.

This release also made some customer suggested improvements to our SSL management component and improved the 2-factor verification process.

You may also notice in this screenshot that we snuck in the return of our $299/mo V-Burst-2 plan. When we trialed this plan last spring it had some strong success but also a we discovered an issue around a lack of clear usage reporting. The V-Burst-2 is based on a t2 AWS instance which has some CPU bursting credits to handle load spikes. Think of Burst credits as a bucket, Burst credits are added to that bucket at a constant rate every minute, they are also withdrawn from the bucket in varying rates depending on how much CPU is being consumed. If the credits are being consumed faster than they are being deposited for some duration of time, the server may run out of burst capability until such time demand drops low enough and the bucket can fill up again.

This bursting feature created a problem for our customers who would see performance drop off sometime around lunch with no apparent cause or reason. The reason was of course is that their sites were keeping the VPS “In Burst” in the morning and draining their bucket. Our answer to this issue is 2 fold – the first of which is to strongly emphasize that this V-Burst-2 plan is ideally suited to serve cache friendly websites, and not recommend it for dynamic sites that utilize WooCommerce, a membership plugin, or makes heavy use of admin-ajax calls. The second is making usage and credit balance reporting available to our customers with an alerting component so they can see exactly how their sites are utilizing the resources at a given time and if they run the risk of degrading their performance. The reporting and alerting component is slated for our next release.

Overall these t2 instance types the V-Burst-2 plan is based on works very well for some, but not all workloads. This is why we feel it is best suited to cache friendly sites that do not tax the CPU as most of the work is done by the PressCACHE layer above the server instead of the PHP workers on the server. If this works for you, the V-Burst-2 plan is available now. It’s also a very simple and painless upgrade to move into a VPS-1 which as a more predictable and constant workload profile.

Our next release will include the V-Burst reporting and alerting component and a new PressDNS interface.

New Posts in your inbox

  1. HI,

    You know what would be really nice? For all your plans to have some burst capacity, even though of course it would be at higher prices than a permanent upgrade. Is that actually technically feasible? Just some security for spikes.
    Dale.