Insourcing, Autonomy, and Independence
Published on December 12, 2025 in Cloud
Hello everyone,As some of you already know, ScalarX operates with very few external technical dependencies (SaaS, and so on).
Recent events around the world (recent incidents involving AWS, Cloudflare, and others), combined with the current political environment, seem to bring us a little closer every day to a loss of individual freedoms and privacy, both personal and professional.
For more than 25 years, I have always worked to build my companies while preserving security and privacy as much as possible, along with the autonomy and independence of both my organizations and those of our clients.
Where We Stand Today
ScalarX is no exception to this rule—quite the opposite: legal and technical structures across several continents, no external shareholders, no exclusive supplier contracts, and a decentralized, multipoint infrastructure operations and maintenance model. Everything was designed with this objective in mind.
Services that directly handle critical data, such as technical support, have always been 100% in-house.
However, a few external services remain. Most are noncritical and depend on third-party providers or vendors (for example, Trello, our accounting system, CRM, SolarWinds, and others).
We will retain some of these services, such as Pingdom, because they provide an independent source of evidence when ScalarX and a client need to assess an incident.
We are not dependent on these services: not only can they be moved to other providers, but we also have internal interactive tools that allow us to surface this information without “breaking” the decentralized nature of monitoring and operational oversight.
What Comes Next
For others, such as Trello or the CRM, we have begun bringing these functions in-house to remove these dependencies. For us, this is the only way to guarantee technically, and not just legally, that no one is “playing” with data that could potentially concern them.
We are using this work to test and certify several of these tools with StackX. In a second phase, we will be able to offer solutions for those who want to deploy them.
At the same time, we are also working on a hardware solution that will allow you to create independent, automated local backups of your hosted sites and applications, in addition to the included backups.
Have an excellent weekend, everyone!
—
Christophe Casalegno
You can follow me on: Telegram | Facebook | LinkedIn | X | YouTube | Twitch
Backup Billing
Published on April 25, 2024 in Uncategorized
Good evening, everyone. Following our year-end inventories, we realized that we had significantly underestimated the amount of backup storage our clients would use. In practice, as I write this, we are currently spending more to store client backups than we bill for them.
This situation will require several actions and individual conversations to put things on a sound footing. What exactly is the situation, and what does it mean for you?
First, the backup price is not changing: it is still billed per GB provisioned, and we do not plan to change the billing system.
There are currently two main types of accounts:
Clients and partners.
Partner accounts are theoretically adjusted based on actual usage, but as with every rule, there are exceptions. In practice, as of today, backup volume is not adjusted to actual usage, but rather to the exact impact of the raw storage cost for us. Put simply, this means that the margin applied is 0% at best (not counting operating costs).
For clients who are not partners, the only adjustments made are based on the amount of production storage used. For example, if a client was using 100 GB of space with an associated backup volume of 100 GB, and production storage increased to 200 GB, the backup volume was increased proportionally.
We do not like surprises, and we assume you do not either. Here is what will happen next:
1) We will conduct a detailed audit of every partner and every client, one by one (some have pooled backups shared across several infrastructures, and so on).
2) We will contact each of you individually with these figures and a set of options. You will be free to choose the one that works best for you, including:
– Adjusting the billed amount to actual usage
– Changing the current retention policy to reduce the space used
– Excluding certain items, with an explanation of the associated risks
– For ScalarCloud or PrivateCloud clients: limiting backups to one type instead of two
– Identifying “suspicious” usage in your user space that you may be able to remove, reducing the amount of backup storage used
In short, there will be many options, allowing each of you to find the right balance and choose the backup policy best suited to your situation.
Wishing you an excellent end to the week.
—
Christophe Casalegno
StackX Now Available for Debian 12 Bookworm
Published on August 28, 2023 in Uncategorized
Hello everyone, our managed LAMP solution (Linux, Apache, MariaDB / MySQL, and PHP), StackX, is now available for Debian 12 Bookworm.
This brings the number of currently supported versions to three: Debian 10, Debian 11, and Debian 12.
The installable versions of MariaDB and MySQL are those available from their respective official repositories. Across StackX, supported MariaDB versions range from 10.3 to 11.2.
The supported PHP versions remain the same across all 3 Debian releases (Buster, Bullseye, and Bookworm):
| PHP 5.6 PHP 7.0 PHP 7.1 PHP 7.2 PHP 7.3 | PHP 7.4 PHP 8.0 PHP 8.1 PHP 8.2 PHP 8.3 |
It is still possible to mix these different versions across multiple sites / applications.
We will soon publish an online table summarizing the versions of the main software supported by each version of StackX.
Have an excellent week, everyone.
Recent Comments