How It Works

Cadence.CI is a DevOps platform built around three principles: observability, collaboration, and security. This page covers the architecture and concepts that underpin the platform.

Core Technology

Cadence.CI relies on Mélodium to implement distributed pipelines by handling data streams, event reactions, and process management in a way that is scalable, reproducible, and fault-tolerant.

Data Streams as First-Class Citizens

Mélodium treats data streams as the fundamental unit of computation. Streams can be distributed, transformed, and processed across multiple nodes, enabling real-time and scalable data handling. Streams are typed and generic, allowing for safe and reusable pipeline code across different data types and environments.

Event-Driven and Reactive Programming

Treatments react to incoming data or events rather than following a predefined execution order. This is particularly useful for integration pipelines, real-time analytics, and distributed task processing where execution depends on data availability.

Cross-Platform Support

Mélodium’s distribution system runs on diverse platforms, from constrained embedded systems to large-scale cloud infrastructure. Abstraction layers handle platform-specific details, letting pipeline authors focus on logic rather than deployment.

Infrastructure and Distribution

Cadence.CI dynamically spawns runners across diverse infrastructures and cloud providers in a truly infrastructure-agnostic way.

Infrastructure Agnosticism

Cadence.CI does not lock users into a single cloud or on-premises environment. Runners can be deployed on:

Public clouds (Scaleway , AWS, GCP, Azure, and more)
Private clouds (OpenStack, VMware, etc.)
On-premises infrastructure (bare metal, Kubernetes clusters)
Hybrid environments (mixing cloud and on-prem)
Third-party provisioned runners (GHA Runners, GitLab Runners)

Dynamic Runner Spawning

Runners are provisioned on demand and terminated when the job completes:

On-demand provisioning: runners spawn only when needed, eliminating idle resource costs.
Auto-scaling: the system scales up or down based on pipeline demand.
Ephemeral runners: each runner is created for a specific job and destroyed afterward, improving both efficiency and security posture.

Unified Abstraction Layer

Mélodium shares pipeline specifications with Cadence.CI regardless of the underlying infrastructure. Cadence.CI translates Mélodium’s requests into provider-specific actions, launching an EC2 instance on AWS, a VM on OpenStack, or a pod on Kubernetes, while presenting a consistent interface to the pipeline author.

Monitoring and Debugging

Cadence.CI provides comprehensive monitoring and granular debugging for Mélodium executions, with real-time log streaming, treatment-level analysis, and full connection tracing.

Real-Time Log Streaming

Cadence.CI aggregates logs from all Mélodium runners in real time, regardless of whether they run on cloud, on-prem, or hybrid infrastructure. Logs are structured and tagged with metadata, runner ID, treatment ID, timestamp, and execution status, making them filterable and searchable from the dashboard.

Treatment-Level Debugging

Each treatment in a Mélodium pipeline is monitored individually. For any treatment you can inspect:

Inputs and outputs: the exact data passed in and out at execution time.
Execution state: start/end times, duration, and exit codes.
Environment context: variables, configurations, and dependencies active during execution.
Intermediate values: data transformations at any point within the treatment.
Error stack traces: detailed error messages for failed treatments.
Resource usage: CPU, memory, and I/O metrics during execution.

Connection Tracing

Cadence.CI maps the connections between treatments, showing how outputs from one treatment become inputs to another:

This makes it possible to answer “where did this value come from?” even in complex multi-runner pipelines, a question that is structurally unanswerable in log-only observability systems. The dependency graph of treatments and connections is always visible, regardless of the number of runners involved.

Time-Travel Debugging

Any treatment can be replayed with the exact same inputs and environment captured at execution time, reproducing failures deterministically without re-running the entire pipeline.

Alerts and Notifications

Custom alerts can be configured for specific log patterns, error codes, resource thresholds, or anomalies such as unusually long execution times. Logs and metrics can be exported to Prometheus, Grafana, or Datadog for further analysis.

Organization and Security

Teams and Roles

Users are organized into teams within an organization. Roles define permissions for projects, pipelines, and runners. Runners and secrets can be scoped to specific teams or projects, and cross-team collaboration is enabled through shared project invitations.

Bring Your Own Infrastructure

Cadence.CI follows a “Bring Your Own Infrastructure” (BYOI) model: pipeline orchestration runs on Cadence.CI, but compute runs on infrastructure you control.

This model provides:

Data sovereignty: sensitive data never leaves your private infrastructure, and runners can be placed in specific regions to meet data residency requirements (GDPR, CCPA, etc.).
Network isolation: runners can be deployed in isolated VPCs, on-prem data centers, or air-gapped environments.
Compliance alignment: because you control the infrastructure, you can meet strict requirements (HIPAA, PCI DSS, SOC 2, ISO 27001) by running on already-certified environments.
Ephemeral and dedicated runners: runners are short-lived and can be scoped to specific teams, eliminating cross-tenant risks.
IAM integration: connect your existing identity provider (Active Directory, LDAP) to manage access to runners and resources.

Core-Level Security

Cadence.CI leverages Mélodium’s runtime properties for security guarantees that are enforced at the execution level, not added on top:

Fail-fast validation: the entire program is validated at startup. Invalid configurations and unsafe setups halt immediately before any runner is spawned or any compute is provisioned.
In-memory secret handling: sensitive values are identified in memory and are never shared across treatments or written to logs. They are securely erased after use.

Programming Language