A service defines the runtime configuration and operational requirements for an application component. It specifies container images, resource requirements, networking configuration, and deployment behavior. When you deploy a service to an environment, it creates an installation—the actual running instance with environment-specific settings applied.

Services function as deployment templates that can be instantiated across multiple environments. Each installation inherits the service’s base configuration while applying environment-specific overrides for variables, scaling parameters, and networking rules. This separation enables consistent application behavior across development, staging, and production environments while allowing necessary customization.

​
Service Types and Runtime Behavior

Ryvn supports five service types that correspond to different application runtime patterns. Each type implements specific scheduling, networking, and scaling characteristics suited to its operational model.

​
Source Configuration and Build Process

Services source their runtime artifacts through two primary mechanisms: GitHub repositories and container registries. The choice affects the build process, versioning strategy, and deployment workflow.

​
GitHub Integration

GitHub-sourced services connect directly to repository branches or tags. Ryvn monitors repository changes and automatically builds new releases when code changes are detected. The build process varies by service type:

  • Server and Worker services: Build container images from Dockerfiles or use buildpacks for source code
  • Chart services: Package Helm charts and validate templates
  • Terraform services: Validate configurations and plan infrastructure changes

Build artifacts are stored in the Ryvn Registry with semantic versioning based on Git tags. Build logs and metadata are preserved for debugging and audit purposes.

​
Container Registry Integration

Registry-sourced services deploy pre-built container images from external registries. This approach suits teams with existing CI/CD pipelines or complex build requirements that exceed Ryvn’s build capabilities.

Image tags determine release versions, with Ryvn automatically detecting new images and creating corresponding releases. The registry integration supports authentication through service accounts and can pull from private registries with appropriate credentials.

​
Release Management and Versioning

Releases represent immutable snapshots of service configuration and artifacts ready for deployment. Each release receives a semantic version number and contains all necessary components: container images, configuration templates, and deployment specifications.

Release creation varies by source type. GitHub services create releases when tags are pushed to the repository, using the tag name as the version number. Registry services create releases automatically when new image tags are detected.

Releases progress through release channels that control deployment timing and environment targeting. A typical flow promotes releases from development to staging to production, with approval gates and automated testing at each stage.

Release metadata includes build information, source commit details, and deployment history. This audit trail enables precise rollback capabilities and change tracking across environments. Failed releases can be quickly replaced with known-good versions without affecting running installations.

​
Service Monitoring and Health Management

Service health encompasses multiple layers: individual pod health, application-level metrics, and cross-environment consistency. Health monitoring operates at both the service level (across all installations) and installation level (within specific environments).

For detailed deployment procedures, see our guides for GitHub deployment, registry deployment, and Helm charts.