Skip to main content

​
Be a framework for Internal Developer Platforms

We’ve built the product with primitives powerful enough for large enterprise use cases. It’s a simple system, but scales to handle immense complexity. While the default on-ramp to Ravion is a bit more PaaS-esque, enterprise platform teams can nuke the Ravion defaults and build out their own platform from scratch.

​
Startups should be able to launch with a hyperscaler or on-prem as easy as with a PaaS

Companies that start on PaaS and become large always end up moving to a hyperscaler like AWS for at least part of their infrastructure. But its understandable because PaaS has traditionally been so much easier to start with. Until Ravion — while there’s still a touch more friction than PaaS, once you connect your hyperscale cloud account the whole cloud becomes your oyster. Then you never have to suffer PaaS reliability problems or do a painful migration.

​
Single pane of glass for infrastructure, builds, deploys, and observability

Ravion is the house for all your infrastructure. The place to keep track of everything. Without Ravion, you can’t open a single window or file and see all your infrastructure and how it is all connected together. Sure you can create cloud architecture diagrams, but they quickly get out of date. Ravion helps humans and agents. It’s a database for your infrastructure so your agents can discover, understand how it is connected, and help you make the right decisions. And it saves tokens and context. Agents don’t have to go search through heaps of accounts, MCP servers, etc.

​
Developers and their agents shouldn’t normally use IaC directly

It’s true, anyone can whip up serious looking IaC in mere minutes. But who is the infrastructure expert that’s going to review and make sure databases aren’t accidentally public and VPC subnets are set up securely? Besides, most developers don’t want to deal with the toil of infrastructure! They just want to git push and have their work live asap. Which means even if you give them pre-built Terraform modules and AI skills, it’s a high chance they end up doing something you don’t want because it was easier to make an innocent looking hack to fix the problem at hand. And now it’s on you, the infrastructure expert, to fix it and try for the 100th time to train them up in the way they should go.

​
IaC should be used through a platform that provides easy, safe paths for developers and agents

The solution is to give developers and agents an intermediate platform that is so easy and simple it makes them want to get up and dance. And on the backend it is running your signed, sealed, and delivered Infrastructure as Code. The platform turns your IaC into re-usable and self-contained modules, and modules can require or allow connections to other modules. With everything tracked in a single place. No bespoke CloudFormation stack hidden in a closet. Devs and agents get to roam freely within the generous but thoughtful boundaries of the platform, and you, the ops person, can sleep well at night knowing the platform is locked down.

​
Config as code is critical

You most likely understand the value of this, so we won’t belabor the point other than to say we agree. All the config in Ravion can be pulled and pushed from our systems at any time with CLI and API. Store the config in your repo, execute dry-run in your pull request, and run config apply on merge to main.

​
Everything customizable with user facing config

You can modify the entire Ravion experience. You can add custom modules alongside our standard library or you can completely replace it. Module definitions use config to define what inputs are possible, what metrics are displayed, what logs are available, and what inputs are required for deploys. You can customize or replace the default Terraform pipelines. You can customize or replace the organization’s Default Values.