In my last post, I talked about the fundamental realization that drove ContextOS: 98% of infrastructures have identical needs, and the current solutions—Kubernetes, service meshes, cloud platforms—have made infrastructure management more difficult, not easier.
Today, I want to explain the core innovation that makes ContextOS different. It's what I call the CTX/ICC construct, and it's the beating heart of everything we've built.
Every developer understands how to use multiple CPU cores on a single computer. You have two basic approaches: threads and processes.
Threads create separate execution contexts inside the OS kernel, allowing your code to have a single memory namespace while executing on multiple physical CPU cores simultaneously.
Processes create new OS processes with their own memory namespaces. When you make multiple processes, you need Inter-Process Communication (IPC) to communicate—typically accomplished on POSIX systems using system sockets or localhost network ports.
This is Computer Science 101. Every good developer gets this.
Here's my light bulb moment: What if we could do the exact same thing, but across multiple physical computers?
This is not a new concept, but I decided to do it in a different way than those who have tried before. Instead of making something like Plan 9 from Bell Labs I wanted to make a system that would run existing applications and not require a new learning curve. Something that could run apps in any OS, but still behave like a distributed OS.
The CTX (Context) is the namesake of ContextOS, the beating heart of what we do. A CTX is like a heavy process. It allows an application to run the exact same code on multiple physical computers—dynamically based on load or static assignment.
Think about what this means: as load on a single CTX rises, ContextOS makes a new CTX somewhere else in your infrastructure. Automatically. Dynamically. Without your application code needing to know or care.
This is the promise that Kubernetes tried to fulfill but completely failed at. K8s made you think in pods, nodes, deployments, replica sets, services, ingresses—a whole new vocabulary of infrastructure primitives. Kubernetes made you rewrite your mental model.
ContextOS doesn't. You're still thinking in familiar terms: execution contexts that can scale. The difference is, now they scale across hardware boundaries transparently.
Of course, the second I envisioned this, I was immediately aware of all the things preventing it from working.
When two instances need to communicate securely across different physical computers, they face an explosion of complexity:
Network Discovery: In dynamic cloud environments where servers appear and disappear based on traffic and containers restart in different locations, services need to dynamically locate each other without manual intervention. Service instances have dynamically assigned network locations that change with autoscaling, upgrades, and failures.
Authentication and Security: Robust authentication mechanisms are needed to ensure each node is authenticated and trustworthy—an unauthenticated node could potentially access sensitive data or disrupt the system. PKI-based solutions that require preliminary key distribution are rendered awkward and contrived in dynamic systems.
Network Traversal: How do you communicate when instances might be on completely different networks, behind different firewalls, across different security zones?
State Synchronization: State synchronization is the hardest problem in running a distributed platform, with distributed systems acting as blast amplifiers that propagate bugs quickly across the network.
Service Registration: Services must announce their availability to a central registry and include authentication and environment details, while also handling deregistration when instances terminate.
This is why Kubernetes environments are drowning in complexity. You need Consul or etcd for service discovery. You need Istio or Linkerd for service mesh. You need cert-manager for certificate management. You need external-dns for DNS management. The list goes on.
Each of these tools solves one narrow slice of the distributed systems problem, and then you're responsible for making them all work together. It's infrastructure Jenga, and one wrong move brings everything crashing down.
The ICC (Inter-Context Communication) is our answer to this entire mess.
The ICC registers CTX instances to each other dynamically. As they spin up, the CTX can communicate with other instances safely, securely, and as if they were located locally.
Read that again: as if they were located locally.
Traditional inter-process communication between processes can incur significantly higher costs—potentially by two or more orders of magnitude—due to overheads such as communication and synchronization. The ICC eliminates this overhead by making distributed communication look and feel like local IPC.
No service mesh configuration. No YAML files defining network policies. No manual certificate management. No DNS configuration. The ICC handles all of it, transparently, as a fundamental property of how CTXs communicate.
Let me make this concrete with a simple example.
You're running a web application. In a traditional setup, you'd define:
In ContextOS, you define a CTX. That's it.
The system automatically:
All of this happens at the infrastructure level, not the application level. Your code doesn't need to know it's distributed. It just scales.
Here's why the CTX/ICC construct matters so much: it's the foundation that makes everything else possible, and it drives all other needs in ContextOS.
To make CTX/ICC work, we had to solve a myriad of distributed systems problems:
Each of these systems exists to support the CTX/ICC construct. And because they're all designed together, working in concert, they provide capabilities that the patchwork of Kubernetes ecosystem tools simply can't match.
Let's come back to the Microsoft research I mentioned in my last post about developers spending too much time on DevOps work.
With the CTX/ICC construct, developers work at the right level of abstraction. They're not configuring service meshes or debugging why a pod can't talk to another pod across namespaces. They're not wrestling with DNS resolution or certificate rotation.
They're writing code that runs in a CTX. The ICC handles making that code work across distributed infrastructure. It's the division of responsibilities we should have had from the beginning.
Using TCP for reliability, TLS for encryption, and DNS for service discovery should ensure smooth communication—but in practice, orchestrating all of these pieces manually is where teams spend their time. ContextOS handles this orchestration automatically as a property of the ICC.
The CTX/ICC construct is elegant in concept but required us to build a powerful platform to facilitate it. I wanted to realize the dream of CTX/ICC, but to do it we needed to build a deeply powerful system.
In my next post, I'll dive into the Virtual File System (VFS)—the shared source of truth that enables ContextOS to maintain distributed state. The VFS is what allows every node in the cluster to have a unified view of the system, and it's central to how we achieve the reliability and consistency that makes CTX/ICC possible.
After that, we'll explore the Distributed State Machine and Software Drivers—the systems that let us deploy and manage complex distributed services with the same reliability and idempotence that you'd expect from a single-machine configuration management tool.
The CTX/ICC construct isn't just a clever abstraction. It's a fundamental reimagining of how distributed computing should work—one that acknowledges the complexity but hides it where it belongs: in the infrastructure, not in your application code.
Tom Hatch is the CEO, CTO and Co-founder of ContextOS. Previously, he created SaltStack, used by 20% of Fortune 500 companies.