# How to Contribute to denoland/celld: Complete Contribution Guidelines

> Learn how to contribute to denoland/celld by emailing patches directly to ry@deno.com. Discover the complete contribution guidelines for this project.

- Repository: [Deno/celld](https://github.com/denoland/celld)
- Tags: how-to-guide
- Published: 2026-09-05

---

**Contribute to celld by emailing patches to ry@deno.com instead of opening pull requests, which are permanently disabled.**

The **celld** repository is Deno's self-hosted, distributed implementation of Cloudflare Durable Objects. While most open-source projects accept GitHub pull requests, celld follows a unique email-based workflow designed to encourage thoughtful, focused contributions and respect maintainer review time.

## Why Celld Uses Patched-Based Contributions

According to the [README.md § Contributions](https://github.com/denoland/celld/blob/main/README.md#L13-L22), pull requests are explicitly disabled. The maintainer explains: *"Thoughtful contributions are welcome; please understand the code, keep the patch focused, and respect the review time you are asking for."*

This workflow ensures contributors deeply understand the codebase before submitting changes and prevents drive-by contributions that burden reviewers.

## Step-by-Step Contribution Process for Celld

### 1. Clone and Prepare Your Changes

Start by cloning the repository and creating a focused branch for your change:

```bash

# Clone the repo

git clone https://github.com/denoland/celld.git
cd celld

# Create a new branch for your change

git checkout -b my-fix

# Edit files ...

```

### 2. Generate a Mail-Friendly Patch

Once your changes are complete and tested, create a patch file using `git format-patch`:

```bash

# Create the patch from your most recent commit

git format-patch -1 HEAD

```

This generates a file like `0001-feat-cli-add-log-level-flag.patch` in your working directory.

### 3. Verify Your Patch Quality

Before sending, review your `.patch` file to ensure it meets these criteria:

- **Single logical change** — one patch per concern
- **Clear commit message** — explain *what* changed and *why*
- **Self-contained** — no dependencies on other pending patches
- **Respects existing conventions** — follow Rust formatting, error handling, and async patterns used in the surrounding code

### 4. Email Your Patch to the Maintainer

Send the patch file as an attachment to **ry@deno.com**. Include a brief message describing:

- The problem your patch solves
- How you tested it
- Any architectural decisions worth noting

### 5. CLA and Review Process

By emailing your patch, you automatically grant Deno Land Inc. a **Contributor License Agreement (CLA)** — no separate signature required. The maintainer will review your patch via email, possibly request revisions, and apply it directly if accepted.

## Understanding Celld's Architecture Before Contributing

Familiarize yourself with these core components to make well-targeted contributions:

| Component | Purpose | Key Files |
|-----------|---------|-----------|
| **Node & Fleet** | V8 isolate runtime and Wrangler bundle processing | [`crates/celld/main.rs`](https://github.com/denoland/celld/blob/main/crates/celld/main.rs) |
| **LTX Log Format** | Durable replication log for write durability | [`crates/ltx/src/ltx.rs`](https://github.com/denoland/celld/blob/main/crates/ltx/src/ltx.rs) |
| **Logic Layer** | Core Durable Object primitives (KV, HTTP, Cron) | [`crates/logic/lib.rs`](https://github.com/denoland/celld/blob/main/crates/logic/lib.rs) |
| **Deployment Protocol** | Wrangler bundle parsing and `celld deploy` behavior | [`crates/celld/deploy.rs`](https://github.com/denoland/celld/blob/main/crates/celld/deploy.rs) |
| **Documentation** | User-facing guides and API reference | [`docs/README.md`](https://github.com/denoland/celld/blob/main/docs/README.md) |

## Practical Example: Adding a CLI Flag to Celld

Suppose you want to add a `--log-level` flag. Here's the complete workflow:

**Edit the argument parser** in [`crates/celld/main.rs`](https://github.com/denoland/celld/blob/main/crates/celld/main.rs) (around line 350):

```rust
// In crates/celld/main.rs
let matches = Command::new("celld")
    .arg(Arg::new("log-level")
        .long("log-level")
        .help("Set logging verbosity")
        .default_value("info"))
    .get_matches();

```

**Update environment handling** in [`crates/logic/lib.rs`](https://github.com/denoland/celld/blob/main/crates/logic/lib.rs) if the flag affects runtime behavior.

**Document the change** in [`docs/README.md`](https://github.com/denoland/celld/blob/main/docs/README.md) under the *Command-line interface* section.

Commit with a clear message:

```bash
git add crates/celld/main.rs docs/README.md
git commit -m "feat(cli): add --log-level flag to control verbosity"

```

Generate and send the patch:

```bash
git format-patch -1 HEAD

# Email 0001-feat-cli-add-log-level-flag.patch to ry@deno.com

```

## Essential Files for Celld Contributors

| File | Role | Why It Matters |
|------|------|--------------|
| [`README.md`](https://github.com/denoland/celld/blob/main/README.md) | Project overview and contribution rules | Read before anything else |
| [`Cargo.toml`](https://github.com/denoland/celld/blob/main/Cargo.toml) (root) | Workspace and dependency declarations | Understand crate structure |
| [`crates/celld/main.rs`](https://github.com/denoland/celld/blob/main/crates/celld/main.rs) | Binary entry point and CLI parsing | Modify for server/node changes |
| [`crates/logic/lib.rs`](https://github.com/denoland/celld/blob/main/crates/logic/lib.rs) | Core Durable Object API implementation | Modify for KV, HTTP, Cron logic |
| [`docs/README.md`](https://github.com/denoland/celld/blob/main/docs/README.md) | End-user documentation | Always update with user-visible changes |
| [`crates/ltx/src/ltx.rs`](https://github.com/denoland/celld/blob/main/crates/ltx/src/ltx.rs) | Replication log format | Modify for durability/replication features |

## Summary

- **No pull requests** — celld contributions must be emailed as patches to ry@deno.com
- **Use `git format-patch`** to generate mail-friendly patch files
- **One change per patch** — focused submissions review faster
- **CLA is automatic** — sending the patch grants license to Deno Land Inc.
- **Know the architecture** — understand [`crates/celld/main.rs`](https://github.com/denoland/celld/blob/main/crates/celld/main.rs), [`crates/logic/lib.rs`](https://github.com/denoland/celld/blob/main/crates/logic/lib.rs), and [`crates/ltx/src/ltx.rs`](https://github.com/denoland/celld/blob/main/crates/ltx/src/ltx.rs) before modifying code

## Frequently Asked Questions

### Why does celld disable pull requests?

The maintainer disables pull requests to ensure contributors understand the code they change and to keep review cycles respectful of maintainer time. The email workflow encourages more deliberate, higher-quality submissions.

### What happens to my patch after I email it?

The maintainer reviews your patch, tests it against the existing codebase and CI, and either applies it directly or responds with feedback via email. There is no GitHub-based review interface.

### Do I need to sign a CLA separately?

No. According to the README, emailing your patch automatically satisfies the Contributor License Agreement requirement with Deno Land Inc.

### Can I contribute documentation fixes the same way?

Yes. Documentation changes in [`docs/README.md`](https://github.com/denoland/celld/blob/main/docs/README.md) follow the identical patch workflow. Ensure your commit message clearly indicates it's a docs change, such as `docs: fix typo in deployment section`.