How to Build Multiple Binaries with Cargo in Rust

By the end of this page, you will understand how Cargo handles multiple binary targets, how to organize a Rust project with src/main.rs, src/bin/, and src/lib.rs, and when to use a single package versus a workspace. You will also see practical layouts for a daemon/client application where both binaries can share common code.

In Rust, Cargo can build more than one binary from the same project. This is useful when your application naturally consists of multiple executables, such as:

• a daemon and a client
• a server and an admin tool
• a CLI plus helper utilities
• a main app plus migration scripts

The key idea is that a Cargo package can contain:

• one library target in src/lib.rs
• one default binary target in src/main.rs
• additional binary targets in src/bin/

Each file inside src/bin/ becomes a separate executable.

For example:

src/
├── lib.rs
├── main.rs
└── bin/
    ├── daemon.rs
    └── client.rs

This package can produce:

• a library crate from src/lib.rs
• a default binary from src/main.rs
• a daemon binary from src/bin/daemon.rs
• a client binary from src/bin/client.rs

If you do not need a default binary, you can omit and keep only plus files in .

Think of a Cargo package like a workshop.

• src/lib.rs is the toolbox shared by everyone.
• each file in src/bin/ is a different worker using tools from that toolbox.
• Cargo is the manager that knows how to build each worker into its own executable.

So instead of cramming daemon logic and client logic into one big program, you let each binary do its own job while both reuse the same library code.

A good mental shortcut is:

• library = shared brain
• binary = entry point

The daemon binary starts the service. The client binary sends commands. Both can call the same Rust library code.

The simplest Cargo layout for multiple binaries is:

my_app/
├── Cargo.toml
└── src/
    ├── lib.rs
    └── bin/
        ├── daemon.rs
        └── client.rs

Basic example

Cargo.toml

[package]
name = "my_app"
version = "0.1.0"
edition = "2021"

src/lib.rs

pub fn run_daemon() {
    println!("daemon logic is running");
}

pub fn run_client() {
    println!("client logic is running");
}

src/bin/daemon.rs

fn main() {
    my_app::run_daemon();
}

src/bin/client.rs

Consider this example:

// src/lib.rs
pub fn greet(name: &str) {
    println!("Hello, {name}!");
}

// src/bin/client.rs
fn main() {
    my_app::greet("client");
}

// src/bin/daemon.rs
fn main() {
    my_app::greet("daemon");
}

What happens when you run cargo build?

1. Cargo reads Cargo.toml.
2. It sees one package named my_app.
3. It checks src/lib.rs and builds the library target.
4. It checks src/bin/daemon.rs and builds a binary named daemon.
5. It checks src/bin/client.rs and builds a binary named .

Multiple binaries in one Cargo package are common in real Rust projects.

Common scenarios

• Daemon + client

  • a background service listens on a Unix socket
  • a client program sends commands to it

• Server + admin tool

  • one binary runs the web server
  • another binary performs maintenance tasks

• CLI + migration utility

  • one binary is the main application
  • another updates databases or generates files

• Worker + scheduler

  • one binary consumes jobs
  • another submits or manages jobs

Why shared libraries help

A shared library avoids repeating:

• configuration parsing
• protocol types
• validation logic
• error types
• utility functions

For your daemon/client example, both programs may share:

• socket path constants
• request and response enums
• serialization code
• error handling helpers

In real projects, developers usually separate responsibilities like this:

Typical pattern

• src/lib.rs
  • core business logic
  • protocol types
  • shared utilities
  • configuration loading
• src/bin/daemon.rs
  • parse CLI args
  • initialize logging
  • bind Unix socket
  • call library functions
• src/bin/client.rs
  • parse CLI args
  • connect to socket
  • send requests
  • display responses

Common patterns

Guard clauses

Binaries often validate inputs early:

fn main() {
    let socket_path = "/tmp/myapp.sock";

    if socket_path.is_empty() {
        eprintln!("socket path cannot be empty");
        std::process::exit(1);
    }

    my_app::run_daemon();
}

Error handling

Many binaries return Result from :

1. Creating custom folders and expecting Cargo to detect them automatically

Cargo automatically understands:

• src/lib.rs
• src/main.rs
• src/bin/*.rs

It does not automatically treat folders like src/daemon/bin/main.rs as binaries unless you declare them explicitly.

Broken expectation

src/
└── daemon/
    └── bin/
        └── main.rs

Cargo will not automatically build this as a binary.

Fix

Either:

• move it to src/bin/daemon.rs, or
• declare it with [[bin]] in Cargo.toml

2. Duplicating shared logic in each binary

Less ideal

// src/bin/daemon.rs
fn parse_config() {
    // duplicated logic
}

// src/bin/client.rs
fn parse_config() {
    // duplicated logic again
}

src/bin/*.rs vs [[bin]]

Cargo multiple binaries quick reference

Default conventions

• Library: src/lib.rs
• Default binary: src/main.rs
• Extra binaries: src/bin/*.rs

Example layout

src/
├── lib.rs
└── bin/
    ├── daemon.rs
    └── client.rs

Run commands

cargo build
cargo run --bin daemon
cargo run --bin client

Share code between binaries

Put shared functions, types, and modules in:

// src/lib.rs
pub fn helper() {}

Use them from binaries:

fn main() {
    my_app::helper();
}

Custom binary paths

[[bin]]
name = "daemon"
path = "src/daemon/bin/main.rs"

Can Cargo build more than one binary in the same project?

Yes. Put extra binaries in src/bin/ or define them explicitly with [[bin]] in Cargo.toml.

How do I share code between a daemon and a client in Rust?

Put the shared code in src/lib.rs, then call it from both binaries.

Should I use src/bin/ or a workspace?

Use src/bin/ for closely related executables in one package. Use a workspace when they should be separate packages.

Does Cargo automatically detect src/daemon/bin/main.rs?

No. Cargo only auto-detects standard locations like src/main.rs, src/lib.rs, and src/bin/*.rs.

How do I run one specific binary when there are multiple?

Use cargo run --bin <name>, for example cargo run --bin daemon.

Can a package have both a library and multiple binaries?

Yes. This is a common and idiomatic Rust project structure.

Is it good practice to keep daemon logic in a library?

• Rust modules — useful for organizing shared code inside lib.rs.
• Rust crates and packages — important for understanding how Cargo groups code and targets.
• Cargo workspaces — relevant when one package with multiple binaries becomes too large.
• Rust main function — helps explain what each binary entry point does.
• Error handling with Result — commonly used in binary entry points.
• Unix sockets in Rust — directly related to daemon/client communication.
• Command-line argument parsing — often needed for client and daemon binaries.
• Rust project structure — helps you understand idiomatic file layouts.