DCanary is the world's first truly decentralized CI/CD platform that brings blockchain-level security and transparency to software deployment. Built on the Internet Computer, it eliminates single points of failure while ensuring cryptographic verification and distributed consensus for every build.
Unlike traditional platforms that rely on centralized infrastructure, DCanary leverages blockchain technology to create an immutable, transparent, and censorship-resistant deployment pipeline.
Every build is cryptographically signed and verified across multiple independent nodes.
No central authority or single point of failure. Runs entirely on blockchain infrastructure.
Familiar CLI tools, GitHub integration, and workflow patterns you already know.
Jump into our quick start guide and have your first decentralized pipeline running in just 5 minutes.
Every build is cryptographically signed and verified across multiple nodes
No central authority, runs entirely on Internet Computer blockchain
All pipeline executions are permanently recorded on-chain
Multiple executors must agree before marking builds as successful
Simple CLI, GitHub integration, familiar workflow patterns
Distributed across the globe with automatic failover
Follow these steps to set up your first decentralized CI/CD pipeline
npm install -g @dcanary/cli
Install the DCanary command-line interface globally on your system. This provides all the tools needed to create, configure, and manage your decentralized CI/CD pipelines.
Note: Requires Node.js 16+ and npm. The CLI will automatically configure your identity and connect to the Internet Computer network.
dcanary init --type nodejs
Set up DCanary configuration for your project type. This creates a dcanary.yaml file with sensible defaults and project-specific build commands.
What this does: Creates configuration files, sets up build stages, configures secrets management, and establishes webhook endpoints for your repository.
dcanary pipeline create --name "My App" --repo "github:user/repo"
Connect your GitHub repository and create your first pipeline. This registers your project with the DCanary network and sets up the necessary smart contracts on the Internet Computer.
Behind the scenes: This deploys your pipeline configuration to a canister, generates unique webhook URLs, and enrolls your project in the consensus network.
dcanary deploy && dcanary status
Deploy your pipeline to the network and monitor its status. Your pipeline is now live and will automatically trigger on code pushes, executing builds across multiple independent nodes.
Success! Your decentralized CI/CD pipeline is now active. Configure webhooks in your repository settings to enable automatic builds on code changes.
Choose your preferred installation method
npm install -g @dcanary/cli
# Verify installation
dcanary --version
curl -fsSL https://install.dcanary.dev | bash
git clone https://github.com/modaniels/dcanary.git
cd dcanary && npm install && npm run build
npm link
| Component | Minimum | Recommended |
|---|---|---|
| Node.js | v16.0.0 | v18.0.0+ |
| RAM | 512 MB | 2 GB+ |
| Storage | 100 MB | 1 GB+ |
| Network | Basic internet | Stable broadband |
| OS | Linux, macOS, Windows | Linux/macOS preferred |
Built on Internet Computer for true decentralization
┌─────────────────────────────────────────────────────────────────┐
│ Internet Computer Network │
├─────────────────────────────────────────────────────────────────┤
│ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Webhook │ │ Pipeline │ │ Verification │ │
│ │ Canister │ │ Config │ │ Canister │ │
│ │ │ │ Canister │ │ │ │
│ └─────────────────┘ └─────────────────┘ └─────────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ Build Executor Canister │ │
│ │ (Orchestrates off-chain executors) │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
└──────────────────────────────┼───────────────────────────────────┘
│
┌──────────────────────┼──────────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Executor #1 │ │ Executor #2 │ │ Executor #3 │
│ (Off-chain) │ │ (Off-chain) │ │ (Off-chain) │
│ │ │ │ │ │
│ ┌─────────────┐ │ │ ┌─────────────┐ │ │ ┌─────────────┐ │
│ │Docker/K8s/VM│ │ │ │Docker/K8s/VM│ │ │ │Docker/K8s/VM│ │
│ │Build Environment│ │ │Build Environment│ │ │Build Environment│ │
│ └─────────────┘ │ │ └─────────────┘ │ │ └─────────────┘ │
└─────────────────┘ └─────────────────┘ └─────────────────┘
Receives and validates Git push events from GitHub, GitLab, and other SCM providers
Stores immutable build configurations, secrets, and deployment instructions
Orchestrates distributed build execution across multiple independent nodes
Validates consensus results and permanently stores execution history
Independent build execution environments
Containerized or VM-based build isolation
Secure communication channels
Digital signatures and hash verification
Modern frontend deployment pipeline
Deploy a React application with automated testing, building, and deployment to a CDN. This example shows how to handle modern frontend workflows with dependency management, testing, and optimized production builds.
name: react-app-pipeline
version: "1.0"
environment:
image: "node:18-alpine"
variables:
NODE_ENV: production
CI: true
stages:
- name: install
commands:
- npm ci --production=false
cache:
paths: ["node_modules/"]
key: "${checksum:package-lock.json}"
- name: lint
commands:
- npm run lint
- npm run type-check
parallel: true
- name: test
commands:
- npm test -- --coverage --watchAll=false
coverage: true
artifacts:
- coverage/
- name: build
commands:
- npm run build
artifacts:
- build/
- package.json
- name: deploy
commands:
- aws s3 sync build/ s3://$S3_BUCKET --delete
- aws cloudfront create-invalidation --distribution-id $CLOUDFRONT_ID --paths "/*"
when: branch == "main"
environment:
variables:
AWS_REGION: us-east-1
secrets:
- NPM_TOKEN
- AWS_ACCESS_KEY_ID
- AWS_SECRET_ACCESS_KEY
- S3_BUCKET
- CLOUDFRONT_ID
notifications:
slack:
webhook: $SLACK_WEBHOOK
channels: ["#deployments"]Git Event Processing Hub
Receives and processes Git webhook events from GitHub, GitLab, and other SCM providers. Acts as the entry point for all pipeline triggers with enterprise-grade security.
Immutable Build Definitions
Stores immutable pipeline configurations, build scripts, and encrypted secrets. Provides version control for your CI/CD definitions with blockchain-level security.
{
"name": "my-app-pipeline",
"stages": [
{"name": "install", "commands": ["npm ci"]},
{"name": "test", "commands": ["npm test"]},
{"name": "build", "commands": ["npm run build"]}
],
"environment": "node:18",
"secrets": ["NPM_TOKEN", "API_KEY"]
}Distributed Build Orchestration
Orchestrates distributed build execution across multiple off-chain executor nodes. Manages job distribution, monitoring, and result collection with consensus verification.
Manages job distribution, monitoring, and result collection.Smart load balancing across executor nodes
Live build progress and health metrics
Cryptographic consensus verification
Byzantine Fault Tolerant Verification
Build jobs are distributed to multiple independent executor nodes (minimum 3, typically 5-7) across different geographical regions for maximum redundancy and security. Each executor receives identical build instructions but operates in complete isolation.
Each executor independently runs the same build in completely isolated environments using containerization or virtual machines. This ensures consistent results while preventing any single point of manipulation.
Executors submit cryptographically signed results including logs, artifacts, and exit codes with tamper-proof digital signatures. Each submission includes comprehensive metadata for verification.
Results are compared and verified using Byzantine fault tolerance - 2/3 majority required for success with full cryptographic audit trail. The verification process ensures no single malicious actor can compromise the build integrity.
Result: When consensus is reached, the verified artifacts are cryptographically sealed and the execution record is permanently written to the blockchain, creating an immutable deployment history.
Enterprise-Grade Protection
Ed25519 signatures for all transactions and communications
AES-256 encryption for all sensitive data and secrets
TLS 1.3 for all communications and data transfer
DCanary uses YAML configuration files to define your build and deployment pipelines. The configuration is declarative, meaning you describe what you want to happen, not how to do it. This ensures consistency and reproducibility across all executor nodes.
name: my-awesome-app
version: "1.0"
# Build environment
environment:
image: "node:18-alpine"
variables:
NODE_ENV: production
# Pipeline stages
stages:
- name: install
commands:
- npm ci --production=false
- name: lint
commands:
- npm run lint
- name: test
commands:
- npm test
coverage: true
- name: build
commands:
- npm run build
artifacts:
- dist/
- package.json
- name: deploy
commands:
- dfx deploy
when: branch == "main"
# Secrets management
secrets:
- NPM_TOKEN
- DEPLOY_KEY
# Notifications
notifications:
slack:
webhook: $SLACK_WEBHOOK
channels: ["#deployments"]Project name, version, and description. Used for pipeline identification and management.
Docker image, environment variables, and runtime configuration for all executors.
Sequential or parallel build steps with commands, conditions, and artifact handling.
Encrypted environment variables and credentials securely distributed to executors.
stages:
- name: deploy-staging
commands:
- deploy-to-staging.sh
when: branch == "develop"
- name: deploy-production
commands:
- deploy-to-prod.sh
when: branch == "main" && tag =~ "^v[0-9]+\\."
- name: security-scan
commands:
- run-security-scan.sh
when: files_changed =~ ".*\\.(js|ts|py)$"stages:
- name: performance-test
commands:
- run-perf-tests.sh
when: |
(branch == "main" || branch == "develop") &&
commit_message !~ "\\[skip perf\\]" &&
time_of_day >= "09:00" && time_of_day <= "17:00"
- name: weekend-maintenance
commands:
- maintenance-tasks.sh
when: day_of_week in ["saturday", "sunday"]stages:
- name: quality-checks
parallel:
- name: lint
commands:
- npm run lint
- npm run format:check
- name: type-check
commands:
- npm run type-check
- name: security-audit
commands:
- npm audit --audit-level high
- snyk teststages:
- name: test-matrix
matrix:
node_version: ["16", "18", "20"]
os: ["ubuntu", "alpine"]
commands:
- npm test
environment:
image: "node:${matrix.node_version}-${matrix.os}"
parallel_limit: 4stages:
- name: install
commands:
- npm ci
cache:
paths:
- "node_modules/"
- "~/.npm/"
key: "${checksum:package-lock.json}-${env.NODE_VERSION}"
restore_keys:
- "${checksum:package-lock.json}-"
- "npm-cache-"
ttl: "7d"stages:
- name: build
commands:
- npm run build
artifacts:
paths:
- "dist/"
- "coverage/"
name: "build-${env.BUILD_NUMBER}"
expire_in: "30d"
public: false
reports:
coverage: "coverage/lcov.info"
test: "test-results.xml"environments:
development:
image: "node:18-alpine"
variables:
NODE_ENV: development
DEBUG: "*"
API_URL: "https://api-dev.example.com"
staging:
image: "node:18-alpine"
variables:
NODE_ENV: staging
API_URL: "https://api-staging.example.com"
resources:
cpu: "1.0"
memory: "2Gi"
production:
image: "node:18-alpine"
variables:
NODE_ENV: production
API_URL: "https://api.example.com"
resources:
cpu: "2.0"
memory: "4Gi"
security:
read_only_fs: true
no_new_privileges: truedcanary webhook get-url --pipeline my-app
Get your unique webhook endpoint URL
In your GitHub repository settings:
dcanary webhook get-secret)dcanary webhook test --pipeline my-app
Verify webhook is working correctly
curl -X POST https://webhook.dcanary.dev/trigger \
-H "Content-Type: application/json" \
-H "X-DCanary-Secret: your-webhook-secret" \
-d '{
"repository": "user/repo",
"ref": "refs/heads/main",
"commits": [{"id": "abc123", "message": "Update code"}]
}'All webhooks are validated using HMAC-SHA256
Restrict webhook sources by IP addresses
dcanary dashboard --web
Launch web dashboard at http://localhost:8080
dcanary status --live
Watch build progress in real-time
Average: 3m 45s
98.5% (last 30 days)
5 nodes online
dcanary logs --follow <build-id>
dcanary logs --build <build-id>
dcanary logs --executor <executor-id>
dcanary logs --errors --last 24h
# Filter by log level
dcanary logs --level error,warn
# Search in logs
dcanary logs --search "compilation failed"
# Filter by time range
dcanary logs --since "2024-01-15 10:00" --until "2024-01-15 11:00"
# Export logs
dcanary logs --export json > build-logs.jsonnotifications:
slack:
webhook: $SLACK_WEBHOOK
channels: ["#deployments", "#alerts"]
on_success: true
on_failure: true
on_timeout: truenotifications:
email:
smtp_server: "smtp.gmail.com"
recipients: ["team@company.com"]
on_failure: true
digest: "daily"Executors couldn't reach consensus on build results. This happens when different executors produce different outputs or when insufficient executors complete the build.
dcanary logs --consensus-details <build-id>
dcanary executor status --all
dcanary debug consensus <build-id>
Pipeline not starting on Git push events. This is usually due to webhook configuration issues or network connectivity problems.
dcanary webhook test --url <webhook-url>
Test webhook endpoint accessibility
dcanary webhook logs --last 24h
Check recent webhook delivery attempts
dcanary webhook validate --repo <repo>
Verify webhook configuration
Executors not joining the network or becoming unavailable during builds. This affects consensus and build reliability.
dcanary executor diagnostics
dcanary network ping --all
dcanary executor health
Builds taking too long or timing out before completion. This can be due to resource constraints, inefficient build processes, or network issues.
# Global timeout settings
timeout:
global: "45m" # Maximum total build time
stage: "15m" # Maximum per-stage time
consensus: "5m" # Consensus agreement timeout
# Per-stage timeouts
stages:
- name: long-running-task
commands:
- run-heavy-process.sh
timeout: "30m"
- name: quick-task
commands:
- quick-script.sh
timeout: "2m"dcanary health --verbose --export health.json
Comprehensive system health report with metrics
dcanary consensus analyze <build-id> --diff
Compare executor results and identify differences
dcanary network topology --live
Real-time network connectivity visualization
dcanary perf analyze --build <build-id>
Detailed timing and resource usage analysis
dcanary perf bottlenecks --last 7d
Identify performance bottlenecks over time
dcanary metrics --grafana --export
Export metrics for external monitoring tools
dcanary debug --export when reporting issuesdcanary init [options]
Initialize a new DCanary project
dcanary pipeline create --name <name> --repo <repo>
Create a new pipeline
dcanary deploy [environment]
Deploy pipeline to network
dcanary status [pipeline-id]
Check pipeline status and recent builds
dcanary secrets add <name> <value>
dcanary secrets list
dcanary secrets delete <name>
dcanary executor start --daemon
dcanary executor join --stake 1000
dcanary executor stats
dcanary logs --follow <build-id>
dcanary debug --export --output debug.json
dcanary validate --config dcanary.yaml
// Trigger a pipeline execution
type TriggerRequest = {
repository: string;
branch: string;
commit_sha: string;
event_type: "push" | "pull_request" | "tag";
};
// Get pipeline execution status
type StatusResponse = {
build_id: string;
status: "pending" | "running" | "success" | "failed";
executors: Array<ExecutorResult>;
consensus_reached: boolean;
};/webhook/github/{pipeline_id}
GitHub webhook endpoint for pipeline triggers
/status/{build_id}
Get build execution status and logs
# Install executor agent
npm install -g @dcanary/executor
# Configure executor identity
dcanary executor init --identity ~/.config/dfx/identity/default
# Start executor daemon
dcanary executor start --daemon
# Join the network
dcanary executor join --stake 1000# Start local replica
dfx start --background
# Deploy to local network
dcanary deploy --network local# Configure mainnet
dcanary config set network ic
# Deploy to mainnet
dcanary deploy --network iccache:
paths:
- node_modules/
- ~/.cargo/
- target/
key: "${checksum:package-lock.json}"stages:
- name: test
parallel:
- npm run test:unit
- npm run test:integration
- npm run test:e2eperformance:
cache:
enabled: true
paths: ["node_modules/", ".cache/"]
resources:
cpu: "4.0"
memory: "8Gi"
parallel_jobs: 3security:
secrets_encryption: true
network_isolation: true
audit_logging: enabled
access_control:
require_2fa: true
session_timeout: "8h"