Dagger launches GitHub checks that run without GitHub Actions

• GitHub pull requests can now trigger Dagger Cloud checks without GitHub Actions, as described in Dagger's launch thread.
• Developers run the same pipelines before and after push, with results in the terminal and PR, as Dagger's demo illustrates.
• The pricing comparison turns on CPU and memory utilization within a job, not just its duration, Dagger argued in its pricing replies.

Memory usage is sampled once per second from Linux cgroups. The underlying 1.0 beta also includes dagger check -i, which opens a shell in the exact state where a command failed.

The October 29 announcement puts Dagger Cloud in charge of receiving GitHub events, executing checks and reporting their status. Setup follows three steps:

1. Configure the repository for Dagger using the getting-started guide.
2. Install Dagger's GitHub app and enable PR checks with dagger cloud checks on.
3. Open a test pull request to verify the integration.

Dagger built the hosting layer after concluding that existing CI providers weren't running its portable engine without wasting compute, according to its explanation for the launch.

Before launch, Dagger raised the comparison with faster GitHub Actions runners. Its 1.0 beta architecture describes five steps underneath the checks:

1. Detect toolchains: recommend official modules, with custom modules also supported.
2. Read native configuration: expose source, containers, binaries, generated files and tests as typed artifacts.
3. Select artifacts: use typed filters for merge gates, preview environments or interactive inspection.
4. Compute lazily: evaluate an incremental DAG of sandboxed functions on a local or remote engine.
5. Integrate execution: give the sandbox, scheduler, container runtime, build cache and tracing one execution and data model.

Dagger Cloud shares execution infrastructure between development and CI:

• Remote development: dagger --engine=cloud runs development pipelines on automatically scaling managed engines.
• Distributed cache: matching operations completed before push can become cache hits when PR checks run.
• Sandboxing: Dagger says execution remains isolated while developers, agents and CI pool compute and cache.
• Failure traces: each GitHub check links to its full Dagger trace, with individual operations and failure context available for inspection.

Pre-push cache reuse is the best part of the launch.

Dagger's pricing page meters four resources separately:

| Resource | New work | Repeat work |
| --- | --- | --- |
| CPU | 0.5¢/CPU-minute | 0.1¢/CPU-minute |
| Memory | 0.5¢/GB-minute | 0.1¢/GB-minute |
| Pipeline inputs | 2.5¢/GB | 0.5¢/GB |
| Pipeline outputs | 10¢/GB | 2¢/GB |

“Repeat work” means an operation with the same inputs as one run in the preceding 30 days. It receives the fivefold discount whether or not it is actually served from cache.

CPU billing uses consumed CPU time from Linux cgroups' cpu.stat. The Starter plan charges the greater of $20 per month or metered usage.

Dagger invited Grok into the pricing argument after asking a commenter to relay its objection to Claude: allocated machine capacity and actual pipeline utilization are different quantities.

Build and test tools leave cores and memory unused even while a job is running, the company argued in its response. Its proposed comparison matches pipeline completion times first, then compares fully loaded costs per run.

Dagger tied the charts to a run on its own repository. It also declined to make blanket savings claims, saying results depend on the workload and that customer numbers would follow as users supplied them.

The open-source engine can run on a laptop or server without paying Dagger, the company confirmed in a reply. Managed Cloud execution remains optional for the engine itself.

Dagger's own rule of thumb favors a self-hosted engine with persistent disk when the CI workload fits on one machine. It frames the managed-service cost comparison around workloads that require a cluster.