GitRiver GitRiver
RU
Navigation

GitOps Deploy (RiverCD)

How to deploy applications to Kubernetes directly from GitRiver: clusters, applications, strategies

RiverCD is a built-in GitOps controller for deploying to Kubernetes. No separate installation is needed: the cluster connects to GitRiver, and deployment is managed from the repository interface.

Why

  • Deploy from GitRiver without external tools
  • See deployment status alongside code and CI/CD
  • Use canary and blue-green deployments
  • Detect drift between the desired and actual cluster state

RiverCD is a free feature, available in Community.

Connecting a Cluster

Before using RiverCD, connect a Kubernetes cluster.

1. Open Administration

Administration -> “Clusters” -> “Add Cluster”

2. Fill In the Details

  • Name - a descriptive name (e.g., “Production”, “Staging”)
  • API URL - the cluster API server address (e.g., https://k8s.example.com:6443)
  • CA Certificate - the cluster’s CA certificate (PEM)
  • Token - a service token for access (Service Account token)
  • Default Namespace - the namespace where resources will be created

3. Test the Connection

Click “Test Connection”. If everything is correct, a success message will appear.

You can connect multiple clusters (multi-cluster) for different environments.

Creating a Deploy Application

A RiverCD application is a link between a repository with manifests and a cluster.

1. Open the Repository

In the repository where Kubernetes manifests are stored, go to the “RiverCD” tab (or “Deploy” - depending on the locale).

2. Create an Application

Click “Create Application” and specify:

  • Name - application identifier
  • Cluster - where to deploy (from the list of connected clusters)
  • Namespace - which namespace
  • Repository path - directory with manifests (e.g., k8s/ or deploy/)
  • Branch - which branch to take manifests from (defaults to the main branch)

3. Synchronize

Click “Synchronize” - RiverCD will apply the manifests from the specified directory to the cluster.

Supported Resources

RiverCD works with any Kubernetes resources:

  • Workloads: Deployment, StatefulSet, DaemonSet, Job, CronJob
  • Networking: Service, Ingress
  • Configuration: ConfigMap, Secret
  • Storage: PersistentVolumeClaim
  • Scaling: HorizontalPodAutoscaler
  • Custom Resources (CRD): any arbitrary resources

Synchronization

Manual Synchronization

Click “Synchronize” on the application page. RiverCD will:

  1. Read manifests from the repository
  2. Compare with the current cluster state
  3. Apply changes (creating, updating, deleting resources)

Automatic Synchronization (auto-sync)

If enabled - RiverCD automatically synchronizes the cluster on every push to the specified branch. You don’t need to click the button manually.

Sync Waves

Order in which resources are applied. For example: ConfigMap first, then Deployment, then Ingress.

Set via an annotation in the manifest:

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "1"

Resources with a lower number are applied first. Default is wave 0.

Hooks (Pre/Post Sync)

Tasks that run before or after synchronization (DB migrations, post-deploy tests):

metadata:
  annotations:
    argocd.argoproj.io/hook: PreSync

Drift Detection

RiverCD compares the desired state (from the repository) with the actual state (in the cluster). If someone changed a resource manually via kubectl - it will be detected.

On the application page:

  • In Sync - the cluster matches the repository
  • Out of Sync - there are discrepancies (diff is shown)

Click “Diff” to see the specific differences.

Image Drift Detection

A separate check: does the image in the cluster match the image in the manifest? Useful if someone manually rolled back an image via kubectl set image.

Deployment Strategies

Rolling (default)

Standard Kubernetes rolling update. Pods are updated gradually.

Canary

Gradual traffic shifting to the new version:

  1. A new version is created with a minimal traffic percentage
  2. You monitor the metrics
  3. Increase the percentage or roll back

Configured when creating/editing the application.

Blue-Green

Two full copies of the application. Traffic switching happens instantly by changing the Service selector:

  1. The “green” version is deployed alongside the “blue” one
  2. You verify
  3. Switch the Service to “green”
  4. Delete the “blue” version

Deployment Monitoring

On the application page, the following are available:

  • Health status - per resource (Healthy, Progressing, Degraded, Missing)
  • Pod logs - click on a pod to see logs
  • Pod diagnostics - container statuses, restart counts
  • Events - timeline of actions (synchronizations, errors, rollbacks)

Rollback

If the new version is unstable:

  1. Open the application in RiverCD
  2. Click “Rollback”
  3. Select a previous version from the synchronization history

RiverCD will apply the manifests from the previous successful synchronization.

Pruning Unused Resources

If you deleted a manifest from the repository - the resource remains in the cluster. To remove it:

  • During synchronization - enable the option “Delete resources absent from the repository”
  • Or click “Prune” on the application page for a one-time removal