In June we rolled out a brand new metrics interface for Cloud Containers, and now the same upgrade has reached all managed servers. Dedicated Servers, Virtual Servers, High Performance VMs - if they're managed by us, you can now see a lot more data about server load, CPU usage, RAM usage, database disk usage and more. Once the data is collected, you'll be able to select periods from 5 minutes to a year. The Knowledge Base explains how to find and filter your data.
We are now running our own gear for Cloud Container customers in California, rather than renting servers there. As well as boosting performance, this gives us direct responsibility for another slice of the Cloud Container platform. It’s also a step towards our goal of making Cloud Containers as standardised as possible around the world.
View any Cloud Container or Cloud Container Server through the SiteHost Control Panel, and you'll see a new metrics widget near the top of screen. Take a quick glance at CPU, memory, disk and load, or click the widget to open your full Metrics suite in a new tab. (This update removes the old "Graphs" tab.) Catch up on the launch of this new Metrics interface in the blog.
Closely monitor your Cloud Container servers and individual containers with a new, detailed Metrics dashboard. Graph out server load, CPU usage, RAM usage, database disk usage and more over periods from 5 minutes to a year (once that much data has been collected). Read the introductory blog article, get more detail from the Knowledge Base, or log into your SiteHost Control Panel and open any Cloud Container (or Cloud Container server) to find the new Metrics link.
Take a look at your list of Cloud Container SSH users and you'll notice that it's had a bit of a tidy-up. As well as visual changes, like switching the 'User Type' to an icon, we've added more details. Now you can see the keys that each user has, without having to click into each one. We've had a lot of requests for this update so we're stoked to deliver it.
When you view your list of Cloud Container backups, you'll now see what image the container was running at the time. If you want to restore a backup that was taken before the image was upgraded or changed, we recommend changing the image back before restoring. See how to restore a Cloud Container backup in the Knowledge Base.
If we manage and monitor your Cloud Containers, there's a new "Production Mode" setting within their environment variables. If this setting is off, we'll know that the container isn't production-ready and we won't monitor the website. When it's on, so is our round-the-clock monitoring.
A little known fact is the Control Panel is eventually consistent for Cloud Containers. That means if a change is made directly on your server (like a container shuts down) or a job takes longer than we expect, that change will appear in the Control Panel soon(ish). We've now made this process much faster (push vs pull) – so the rare scenario where information might not have been quite up-to-date is now even rarer!
When logged into a container via SSH/SFTP there were certain scenarios where your session could be rudely terminated, one example being when a database was created and linked to that container. This was annoying, so we've carefully audited this behaviour to improve our manners and will no longer unceremoniously destroy sessions unless it is absolutely required.
Every time you spin up a new Cloud Container server, a database container is automatically created. This used to be a MySQL container, but we've now switched to MariaDB. MySQL is still an option, just not the default. Only new servers will be affected. You can read why we've made this change on the blog.
The heading says it all, really. We've released a new service image for Cloud Containers, NodeJS 20. To upgrade older NodeJS containers is a simple matter of swapping images (the Knowledge Base explains how) - and then checking that your application still works, of course.