To help achieve the best possible price for you, we deploy our servers at a scale, pace, and expectation that helps us keep the costs low, to your benefit. However, this also means we defer maintenance on server failures until scheduled maintenance windows.
If the unfortunate situation occurs where a server fails, a replacement server is provided in your registration slot with the same OS and keys as the original was provisioned with. See also: Backups and Data Recovery.
Because of this, we have found the workloads that work best on these servers are for ephemeral scalable services which are spread across regions/pods, such as application farms.
The best parallel to this behavior are the lower-cost “Spot” instances at AWS, which have a lower price-point, but can be shut down as circumstances change.
As described prior, these servers are designed for distributed availability, so any single server is not 5-9. If you need 5-9 SLA, you can still reach that, through your software design. Setup your service crossing multiple zones, and you now have a higher availability, at a lower cost.
For your protection and security, there are no secondary systems maintaining data backups of your servers, and no data assurance This means if there is a failure of the hardware, the data may be lost. You are responsible for data backups on your systems.
When a server is offline due to hardware faults, the time it is offline is not counted as billable time until the replacement server is brought online, and your server registration is preserved from the original registration period (for the purpose of duration discounts).
We have standardized our server configurations to bring you the best price possible. This means that, unfortunately, the hardware configuration is not changeable. The servers are as-is as-available and are not alterable.
Depending on the size of your request, we might be able to create a new product to meet your needs—contact a Sales Representative for more details.
At Cato Digital, we believe a green internet is essential. We work with numerous partners and distributors to ensure our servers are upcycled, carbon-accounted, and as environmentally friendly as possible. This involves saving functional hardware from the landfill, refurbishing as necessary, and reusing those systems.
As we grow, we plan to incorporate as much renewable energy into our operations as possible to achieve carbon-neutral compute.
Using the Cato Metal Console you can start, stop, and configure things like server ports and networks, as well as accessing the server’s console.
Similar to a cloud server, you provide an SSH key, and we provision a Linux Operating system (selected from those available), and you can then access it via SSH with the given credentials.
Currently Linux is the only operating system available, as either Rocky/9 (RHEL/Centos Family) or Ubuntu 22.
After an instance is deregistered and returned to Cato, we go through a data remanence scrubbing process that involves multiple passes on the storage following industry standard practices (such as by DoD 5220 specification).
Because accessing data remanents after data has been erased requires physical access to the storage, when any storage media is at its end-of-life and is decommissioned from service we physically destroy the media.
For our Autonomous Intelligence to properly manage all servers, we retain control of the BIOS and Firmware, and access is restricted from individual tenants. Tenant needs, such as to the server console, are provided through the Cato Metal Console.
For the highest security possible, each Baseboard Management Controller (BMC) is isolated per server on an internal private LAN, which can only be accessed by the Cato Metal controller and allows for no outbound access. That is, each BMC controller is on a discrete/private LAN from the others.
From within the operating system of a host, you may have access to change settings within the BMC or BIOS. However, this is prohibited in your terms and conditions. Changing BMC or BIOS settings will cause your server to be taken offline until the settings are reconciled.
Each server is given one public IP address as part of the package. In the future, we will allow you to create private VLANs directly through the console. Until that feature is available, Private VLANs can be created through a services engagement.
Private VLANs are restricted to the Region/Pod of the server.
When using Private VLANs your server port is set up with 802.1q trunking.
At this time, there are no load-balancer or higher-level network services available, but these services are on our roadmap. You can create these services on your servers, however.
To facilitate the greatest level of customer privacy and flexibility, we use 802.1q port trunking at the server level, and we map private VLANs and VXLANs based on each customer’s need.
By default, each server has three 8012.1q VLANs:
Additional VLANs may be added for other needs, such as storage.
Our systems are set up in Areas, and within each area are multiple Zones which have Pods. Each pod is a cluster of interconnected systems, and within the pod you can recognize the full speed of your network connections as you interconnect with other servers in that pod, either through the public network or private LAN.
Pods are analogous to Availability Zones, but are focused on integration of networking, rather than availability.
We recommend for your systems to achieve the highest level of availability, that you create instances across zones as part of a cluster, if not across regions (using the internet in both cases). See section on Networking about Private LAN limitations.
Because pricing may vary between zones, registrations are not transferable across a zone.