# Growing the workshop: welcoming a new Samuel
Workshops grow the same way good systems do: deliberately.
We’re excited to announce a new addition to the team — Samuel Flores. And yes, this means there are now two Samuels at Alshival.Ai.
To avoid confusion: Samuel Flores, who we shall refer to as *Sam* from now on, is not the same Samuel who serves as our Chief Data Scientist. Sam is joining us to lead something equally critical, but on a very different layer of the stack — field hardware operations.
As much as we love software, a meaningful part of our work lives in the physical world. We provide data center support for some of our clients. We assist with onsite network and security services. We handle data communications infrastructure — the cables, switches, routers, racks, and systems that quietly keep everything online.
That kind of work requires precision, discipline, and someone who understands that uptime isn’t theoretical. It’s physical. It’s logistical. It’s boots-on-the-ground problem solving.
Bringing Sam on board strengthens that capability. He’ll be leading field hardware operations, helping us expand and formalize the way we support client infrastructure — from data center environments to onsite network and security deployments.
As we continue building cloud experiments like Alshival.Cloud and monitoring systems like Resource Manager, it’s important that our operational backbone grows alongside them. Software and hardware aren’t separate worlds for us — they’re parts of the same system.
And now, with two Samuels, that system just got stronger.
# The “what if…?” that turned into Alshival.Cloud
Alshival.Cloud started with a question that’s equal parts playful and serious: **“What if… I could be a cloud provider?”**
The idea became tangible: a data rack, an edge router, a switch, and a cluster of Raspberry Pis — plus the discipline required to keep it all reliable. The end goal isn’t just “hardware in a closet.” It’s a real offering where people can rent dedicated compute without feeling like they’re paying a tax for every click, every gigabyte, and every surprise line item.
One of the most exciting parts of this project isn’t just the hardware itself — it’s everything required to operate it well. We’ve been working on the Raspberry Pi management software that makes the whole thing manageable at scale, and our hope is to share that source code soon.
# DevTools: letting people test the workshop before we “productize” it
If Alshival.Cloud is our infrastructure playground, **DevTools** is our software playground.
DevTools is a way to give people access to internal tools we’re actively experimenting with — before we declare them “done,” polish them, or package them as a full release. It’s for builders who like seeing the process, not just the final result. For supporters, alike.
One of the tools we’ve been testing through DevTools is our **Resource Manager**.
The Resource Manager is built around a practical anxiety every operator knows: you don’t want to find out something is down because a user tells you. So the Resource Manager keeps watch over resources like API endpoints and virtual machines, and it can trigger an Ai agent to reach out when the status changes. You can ask the Ai agent for specific details, ask it to check logs, etc.
We’re taking this a step further with a version of Resource Manager we’re currently building: a **self-deployed** edition designed to run inside secure environments. The goal is straightforward: if your resources live in a locked-down virtual private cloud, you should be able to deploy the monitoring system *inside the VPC* and still get meaningful visibility without compromising the boundaries that keep that environment secure.
Workshops grow the same way good systems do: deliberately.
We’re excited to announce a new addition to the team — Samuel Flores. And yes, this means there are now two Samuels at Alshival.Ai.
To avoid confusion: Samuel Flores, who we shall refer to as *Sam* from now on, is not the same Samuel who serves as our Chief Data Scientist. Sam is joining us to lead something equally critical, but on a very different layer of the stack — field hardware operations.
As much as we love software, a meaningful part of our work lives in the physical world. We provide data center support for some of our clients. We assist with onsite network and security services. We handle data communications infrastructure — the cables, switches, routers, racks, and systems that quietly keep everything online.
That kind of work requires precision, discipline, and someone who understands that uptime isn’t theoretical. It’s physical. It’s logistical. It’s boots-on-the-ground problem solving.
Bringing Sam on board strengthens that capability. He’ll be leading field hardware operations, helping us expand and formalize the way we support client infrastructure — from data center environments to onsite network and security deployments.
As we continue building cloud experiments like Alshival.Cloud and monitoring systems like Resource Manager, it’s important that our operational backbone grows alongside them. Software and hardware aren’t separate worlds for us — they’re parts of the same system.
And now, with two Samuels, that system just got stronger.
# The “what if…?” that turned into Alshival.Cloud
Alshival.Cloud started with a question that’s equal parts playful and serious: **“What if… I could be a cloud provider?”**
The idea became tangible: a data rack, an edge router, a switch, and a cluster of Raspberry Pis — plus the discipline required to keep it all reliable. The end goal isn’t just “hardware in a closet.” It’s a real offering where people can rent dedicated compute without feeling like they’re paying a tax for every click, every gigabyte, and every surprise line item.
One of the most exciting parts of this project isn’t just the hardware itself — it’s everything required to operate it well. We’ve been working on the Raspberry Pi management software that makes the whole thing manageable at scale, and our hope is to share that source code soon.
# DevTools: letting people test the workshop before we “productize” it
If Alshival.Cloud is our infrastructure playground, **DevTools** is our software playground.
DevTools is a way to give people access to internal tools we’re actively experimenting with — before we declare them “done,” polish them, or package them as a full release. It’s for builders who like seeing the process, not just the final result. For supporters, alike.
One of the tools we’ve been testing through DevTools is our **Resource Manager**.
The Resource Manager is built around a practical anxiety every operator knows: you don’t want to find out something is down because a user tells you. So the Resource Manager keeps watch over resources like API endpoints and virtual machines, and it can trigger an Ai agent to reach out when the status changes. You can ask the Ai agent for specific details, ask it to check logs, etc.
We’re taking this a step further with a version of Resource Manager we’re currently building: a **self-deployed** edition designed to run inside secure environments. The goal is straightforward: if your resources live in a locked-down virtual private cloud, you should be able to deploy the monitoring system *inside the VPC* and still get meaningful visibility without compromising the boundaries that keep that environment secure.