Skip to main content
Ryvn uses a resource-based infrastructure-as-code format where each resource (Service, Environment, Blueprint, etc.) is defined in its own YAML file. Resources follow a consistent structure with kind, metadata, and spec fields, making it easy to organize, version, and manage your infrastructure.

​
Structure

Each resource follows a standard pattern: 
# yaml-language-server: $schema=https://api.ryvn.app/v1/schemas/resources.json
kind: Service
metadata:
  name: api
spec:
  type: server
  # Service configuration...
All resources follow the same structure:
  • kind - The type of resource (Service, Environment, Blueprint, etc.)
  • metadata.name - The name of the resource (must be unique within its kind)
  • spec - The resource-specific configuration
Resources are automatically discovered by Ryvn when you configure Git Sync. Ryvn recursively scans all YAML files from your entry point directory. There’s no required folder structure—you can organize files however you prefer. Ryvn identifies resources by their kind field, not their file location or naming.
Add # yaml-language-server: $schema=https://api.ryvn.app/v1/schemas/resources.json at the top of your resource files to enable autocomplete and validation in editors that support YAML Language Server (VS Code, Neovim, etc.).

​
Services

Services define what you’re deploying. Ryvn supports multiple service types:
  • Server - Long-running web applications, APIs, and microservices
  • Job - One-time or scheduled batch jobs and background tasks
  • Helm Chart - Pre-packaged Kubernetes applications
  • Terraform - Infrastructure resources managed by Terraform
Each service defines how to build or source your application—from GitHub repositories, Docker images, or Helm charts.

​
Environments

Environments define where your services run. Each environment represents a deployment target in a customer’s cloud account:
  • AWS - Deploy to Amazon Web Services
  • GCP - Deploy to Google Cloud Platform
  • Azure - Deploy to Microsoft Azure
Environments specify cloud provider settings, networking configuration, and contain a list of installations.

​
Installations

Installations connect services to environments. They define environment-specific configuration for each service deployment: Each installation can override defaults and customize behavior for its specific environment.

​
Blueprints

Blueprints package multiple services together as reusable deployment units. They enable you to define common deployment patterns with configurable inputs, making it easy to deploy complete stacks across environments.
  • Blueprint - Package services with inputs for customization
  • Preview - Automatic preview environments for pull requests
Blueprints can be installed into environments just like individual services. Previews use blueprints to automatically create isolated environments for testing pull requests before merging.

​
Releases

Ryvn provides several features for managing how releases are promoted and deployed across environments:
  • Deploy from branches - Configure one or more branches on a service to create releases automatically on push. Each branch gets its own release channel (branch:main, branch:staging, etc.). See the build.branches property on service types.
  • Release Channels - Define channels like staging, production, and stable for progressive rollouts
  • Promotion Pipelines - Automate release promotion with manual, timed, or canary criteria
  • Maintenance Windows - Control when automated deployments can occur
These features work together to ensure safe, controlled rollouts across your deployment environments.

​
Drift Protection

When Git Sync is active and you modify a resource through the dashboard or API, Ryvn marks it as drifted and prevents git sync from overwriting your changes. You can export dashboard changes to a git branch or remove protection to re-sync from git. See the Drift Protection guide for details.

​
Outputs

Environments and installations can expose outputs that other installations can reference via template syntax. This enables dynamic configuration based on provisioned infrastructure:
  • Environment outputs like cluster names, VPC IDs, and DNS domains (see environment-specific docs: AWS, Azure, GCP)
  • Installation outputs from Terraform modules and other services (see Terraform Outputs)
Use template expressions like {{ .ryvn.env.state.cluster_name }} or {{ (serviceInstallation "database").outputs.endpoint }} to reference these values in your configuration. This reference documentation is organized by resource type:
  1. Core Resources - Dive into specific service types, environments, and installations
  2. Properties - Each page documents all available configuration properties
  3. Examples - See complete, working configurations at the bottom of each page
Start with the service type you want to deploy, then explore the corresponding environment and installation documentation.