GitOps Integration
Yuptime is designed for GitOps workflows. All configuration is in CRDs, making it perfect for Flux, Argo CD, or any GitOps tool.
Design Principles
- Git is the source of truth — Monitor specs live in Git
- Controller only writes status — Never modifies spec
- Declarative configuration — Apply desired state, controller reconciles
Flux
HelmRelease
yaml
apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata:
name: yuptime
namespace: flux-system
spec:
type: oci
interval: 5m
url: oci://ghcr.io/briansunter/yuptime/charts
---
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
name: yuptime
namespace: yuptime
spec:
interval: 5m
chart:
spec:
chart: yuptime
version: ">=0.0.18"
sourceRef:
kind: HelmRepository
name: yuptime
namespace: flux-system
values:
mode: productionKustomization
yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: yuptime-monitors
namespace: flux-system
spec:
interval: 5m
path: ./monitoring/yuptime
sourceRef:
kind: GitRepository
name: fleet-infra
prune: trueArgo CD
Application
yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: yuptime
namespace: argocd
spec:
project: default
source:
chart: yuptime
repoURL: ghcr.io/briansunter/yuptime/charts
targetRevision: 0.0.18
helm:
values: |
mode: production
destination:
server: https://kubernetes.default.svc
namespace: yuptime
syncPolicy:
automated:
prune: true
selfHeal: trueDirectory Structure
Organize monitors in Git:
monitoring/
├── yuptime/
│ ├── namespace.yaml
│ ├── settings.yaml
│ ├── monitors/
│ │ ├── api.yaml
│ │ ├── database.yaml
│ │ └── cache.yaml
│ ├── maintenance/
│ │ └── weekly.yaml
│ └── kustomization.yamlBest Practices
- Organize by service/team — Group related monitors
- Use labels consistently — For selection and routing
- Version control everything — Monitors, settings, maintenance windows
- Review changes — PRs for monitor changes like code