Multi-source services

Combine Helm charts, Git manifests, and custom renderers in a single atomic deployment

Multi-source services let you assemble manifests from more than one origin—typically an upstream Helm chart plus Git-managed YAML—and ship them to the cluster as a single ServiceDeployment. The deployment operator renders each piece, merges the result, and applies everything in one sync.

The most common use case is deploying an operator and its custom resources together: install the operator from a Helm chart, then apply the CRs that configure it from your infra repo, without splitting them into separate services or worrying about race conditions during rollout.

Example: datastore operator + custom resources

Here's a basic example using our datastore-operator (which manages things like elasticsearch indexes and postgres databases via GitOps):

yaml

apiVersion: deployments.plural.sh/v1alpha1
kind: ServiceDeployment
metadata:
  name: datastore-operator
  namespace: infra
spec:
  namespace: elastic
  cluster: mgmt
  sources:
  - repositoryRef:
      kind: GitRepository
      name: infra
      namespace: infra
    git:
      folder: services/datastores # location in git
      ref: main
    path: datastore-crs # location in tarball delivered to deployment-operator
  renderers:
  - path: datastore-crs
    type: RAW
  helm:
    url: https://pluralsh.github.io/console
    version: 0.0.46
    chart: datastore

The Git folder services/datastores holds the operator's custom resources, for example:

yaml

# services/datastores/elastic.yaml
apiVersion: dbs.plural.sh/v1alpha1
kind: ElasticsearchCredentials
metadata:
  name: elasticsearch
spec:
  url: http://elasticsearch-es-http.elastic:9200
  username: elastic
  passwordSecretKeyRef:
    name: elasticsearch-es-elastic-user
    key: elastic

yaml

# services/datastores/ilm.yaml
apiVersion: dbs.plural.sh/v1alpha1
kind: ElasticsearchILMPolicy
metadata:
  name: plrl-ilm
spec:
  name: plrl-ilm
  credentialsRef:
    name: elasticsearch
  definition:
    policy:
      phases:
        warm:
          min_age: 5d
          actions:
            forcemerge:
              max_num_segments: 1
        delete:
          min_age: 7d
          actions:
            delete: {}

Because both the Helm release and the CRs belong to one service, they share a revision, drift detection, and sync lifecycle.