Vision · November 2025

TL;DR

Cloud vendors lock you in. Moving workloads between providers means rebuilding everything. RunOS is an abstraction layer that sits between your apps and hardware. You get managed services, auto-scaling, and monitoring, but the servers can be from anywhere: AWS, Hetzner, your own hardware, or a mix. Same platform, any infrastructure. We’re building enterprise features, multi-cluster deployments, and IaC abstraction so complex infrastructure becomes simple. No vendor lock-in. All open source services.

I’ve watched too many companies get stuck in the same trap.

You start on AWS. Or Google Cloud. Or Azure. Doesn’t matter which. They’re all great platforms with amazing features.

Then you want to experiment. Maybe you need GPUs for a machine learning workload. Maybe you found a cheaper provider for batch processing. Maybe you want servers in a specific region the big clouds don’t cover.

And suddenly you realize: you’re locked in.

The problem nobody talks about

At every company I worked for, we hit this wall. We’d look at our AWS bill. We’d see workloads that could run somewhere cheaper. We’d want to try different providers for different use cases.

But moving infrastructure between cloud providers? That’s a nightmare.

Your whole stack is built around AWS services. Or GCP services. Or Azure services. Everything talks to everything else using their specific APIs and integrations.

Want to move a workload to Hetzner because it’s way cheaper? Good luck rebuilding your entire deployment pipeline, monitoring setup, logging infrastructure, and service mesh.

Want to try running some workloads on bare metal in a colocation facility? Hope you enjoy spending months setting up Kubernetes clusters, configuring networking, and getting monitoring working.

It should be like switching databases

Think about how you choose a database for an application. PostgreSQL or MySQL? You pick what works best. Need to switch later? It’s not trivial, but it’s doable. With the right abstractions in place, switching between databases becomes much simpler.

Your infrastructure provider should work the same way.

That’s what RunOS is about. An abstraction between your applications and the hardware they run on.

You get all the benefits of modern cloud platforms: managed databases, auto-scaling, monitoring, logging, security. But the servers underneath? Those can be from anywhere.

Real flexibility

Here’s what this actually means:

• Run your production workload on AWS for their network speed and reliability
• Run your batch processing on Hetzner because it’s 70% cheaper
• Spin up GPU instances wherever GPUs are available and affordable
• Test new providers without rebuilding your infrastructure
• Mix providers in a single cluster if you want
• Move workloads between providers without changing your deployment process

Same software platform. Different hardware underneath. Your choice.

The vision

We’re building managed services like RDS and EKS, but without the lock-in.

Want a managed PostgreSQL database? Click to install. It runs on whatever servers you point RunOS at. AWS, GCP, Hetzner, your basement server. Doesn’t matter.

The database is highly available, automatically backed up, monitored, and maintained. Just like RDS. But you own the infrastructure.

Same for Redis, Kafka, monitoring tools, whatever you need. One-click managed services, your choice of hardware.

Enterprise features without enterprise lock-in

Big companies need certain things. Compliance. Security. Audit trails.

We’re building all of that into RunOS:

• Full audit logs of every change (who installed what, when, why)
• SSO integration for team access
• SOC2 compliance
• Automatic security updates
• Secrets management with auto-rotation
• High availability configurations

These features are in the pipeline. The goal is to give you everything enterprises expect from cloud providers, without tying you to one vendor.

Making hard things easy

Setting up Kubernetes isn’t hard. What’s hard is:

• Keeping everything up to date
• Managing version compatibility between services
• Configuring high availability correctly
• Setting up automatic failovers that actually work
• Managing secrets and rotating credentials
• Getting monitoring and logging working properly
• Making sure backups actually restore when you need them

This is what DevOps teams spend their time on. This is what breaks during outages because one config step was missed.

RunOS handles all of this. We’ve done the hard configuration work. We’ve tested the failovers. We’ve verified the backups restore correctly.

As more people use the system and trust it, it gets more reliable. Configurations get battle-tested across hundreds of deployments.

Auto-scaling across providers

Need more capacity? RunOS can automatically spin up new servers.

But here’s where the abstraction really pays off: you can define a pool of potential providers. AWS for low-latency workloads. Hetzner for batch processing. Whatever mix you want.

RunOS requests new instances based on your rules, from whichever provider makes sense for that workload. Automatically.

When demand drops, it scales back down. You only pay for what you use.

Multi-cluster deployments and disaster recovery

Here’s another hard problem: running applications across multiple clusters. Maybe you want geographic redundancy. Maybe you need to move a database from one region to another because of a disaster.

Moving a PostgreSQL database between clusters that are geographically spread? That’s not a simple task. You need to automate the migration, test it regularly to make sure it still works, figure out the best practices through trial and error.

Want to set up automatic failover for a service between clusters? That requires careful orchestration, testing, and monitoring to make sure it actually works when you need it.

This stuff is hard to get right. It takes many minds, lots of testing, and learning from mistakes. We’re building those best practices into RunOS so you don’t have to figure it all out yourself.

Simple IaC that does complex things

Defining multi-cluster scenarios with infrastructure as code gets messy fast. The YAML files multiply. The configs get complex. Maintaining it becomes a full-time job.

RunOS is going to abstract this. You define what you want with minimal IaC code. RunOS turns that into all the necessary configs, YAMLs, and workloads.

One simple definition becomes dozens of configurations behind the scenes. You describe the outcome you want. RunOS handles the implementation details.

Built-in observability

Every Kubernetes setup needs logging, metrics, and monitoring. Usually you spend days or weeks setting this up.

RunOS includes it all out of the box. Logs are collected. Metrics are tracked. Alerts are configured. It just works.

Because it’s the same platform regardless of where your servers are, your monitoring setup is consistent whether you’re running on AWS, Hetzner, or your own hardware.

The real goal

Cloud providers aren’t the enemy. AWS, GCP, Azure are incredible platforms with amazing engineering.

But you should have choices. You should be able to use the best tool for each job. You should be able to optimize costs without rebuilding everything. You should be able to experiment with new providers without massive risk.

RunOS gives you that flexibility while keeping all the conveniences of modern cloud platforms.

Same easy deployments. Same managed services. Same enterprise features. But the hardware underneath? That’s up to you.

Try it yourself

Join the beta and see how RunOS works on real infrastructure

Join Beta Program

What we’re building

This is just the start. We’re constantly adding features, improving reliability, expanding the service catalog.

The goal is to make infrastructure simple enough that developers can manage it themselves, but powerful enough that enterprises can trust it for production workloads.

No vendor lock-in. No proprietary services. Just good software running on whatever hardware makes sense for you.

Infrastructure should give you freedom, not trap you.