# Main Entry Point for Running a Fuel Core Node: Binary Startup Path Explained

> Discover the main entry point for running a Fuel Core node. Learn how the binary startup path initializes the node service via the main function and CLI arguments.

- Repository: [Fuel Labs/fuel-core](https://github.com/FuelLabs/fuel-core)
- Tags: internals
- Published: 2026-03-06

---

**The main entry point for running a Fuel Core node is the `main` function in [`bin/fuel-core/src/main.rs`](https://github.com/FuelLabs/fuel-core/blob/main/bin/fuel-core/src/main.rs), which delegates immediately to `cli::run_cli()` to parse arguments and launch the node service.**

When working with the **FuelLabs/fuel-core** repository, identifying the **main entry point for running a Fuel Core node** is critical for tracing startup logic, configuration loading, and service initialization. The executable code path begins in the dedicated binary crate and follows a strict delegation pattern from the async runtime through the CLI layer to the core orchestration service.

## Binary Entry Point in [`main.rs`](https://github.com/FuelLabs/fuel-core/blob/main/main.rs)

The absolute beginning of execution starts in [`bin/fuel-core/src/main.rs`](https://github.com/FuelLabs/fuel-core/blob/main/bin/fuel-core/src/main.rs). This file contains the top-level `main` function annotated with `#[tokio::main]` to initialize the asynchronous runtime before any node logic executes.

```rust
#[tokio::main]
async fn main() -> anyhow::Result<()> {
    cli::run_cli().await
}

```

This minimal wrapper immediately forwards control to the CLI implementation, separating Tokio runtime setup from application-specific initialization.

## CLI Bootstrap and Argument Parsing ([`cli.rs`](https://github.com/FuelLabs/fuel-core/blob/main/cli.rs))

The `cli::run_cli()` function, defined in [`bin/fuel-core/src/cli.rs`](https://github.com/FuelLabs/fuel-core/blob/main/bin/fuel-core/src/cli.rs), handles the heavy lifting of node initialization. According to the FuelLabs/fuel-core source code, this function performs three critical tasks: initializing the **tracing** logging framework, parsing command-line arguments via **clap**, and dispatching to the appropriate sub-command handler.

By default, invoking the `run` sub-command without explicit chain configuration triggers `local_testnet_chain_config()` and `local_testnet_reader()`, both defined in this same file, to load the preset genesis state and consensus parameters for local development.

## Service Initialization and the Run Command

### Run Sub-Command Implementation

The concrete node startup logic lives in [`bin/fuel-core/src/cli/run.rs`](https://github.com/FuelLabs/fuel-core/blob/main/bin/fuel-core/src/cli/run.rs). When the user executes the `run` sub-command, this module constructs a `FuelService` instance and spawns all required background tasks including consensus, networking, and storage layers.

### Core Node Service Architecture

The `FuelService` struct itself is exported from [`crates/fuel-core/src/service/mod.rs`](https://github.com/FuelLabs/fuel-core/blob/main/crates/fuel-core/src/service/mod.rs). This crate represents the heart of the node, exposing `FuelService::new_node(...)` to orchestrate database connections, the transaction pool, block production, and peer-to-peer networking. The CLI run command invokes this constructor to bring the node online.

## Launching a Local Testnet Node

To start a node using the default local-testnet configuration, build the binary from the `fuel-core` crate and execute the run command with your desired parameters:

```bash

# Build the release binary

cargo build --release -p fuel-core

# Start the node with default local testnet settings

./target/release/fuel-core run \
  --db-path ~/.fuel/db \
  --service-name my-fuel-node \
  --max-database-cache-size 1073741824

```

The binary automatically applies the local testnet chain configuration unless you specify a custom snapshot via additional flags.

## Summary

- The **entry point** is `main()` in [`bin/fuel-core/src/main.rs`](https://github.com/FuelLabs/fuel-core/blob/main/bin/fuel-core/src/main.rs), which runs under Tokio's async runtime.
- **CLI parsing** occurs in [`bin/fuel-core/src/cli.rs`](https://github.com/FuelLabs/fuel-core/blob/main/bin/fuel-core/src/cli.rs) via `cli::run_cli()`, which sets up logging and dispatches sub-commands.
- The **run sub-command** in [`bin/fuel-core/src/cli/run.rs`](https://github.com/FuelLabs/fuel-core/blob/main/bin/fuel-core/src/cli/run.rs) instantiates `FuelService` and starts background workers.
- **Core service logic** resides in [`crates/fuel-core/src/service/mod.rs`](https://github.com/FuelLabs/fuel-core/blob/main/crates/fuel-core/src/service/mod.rs), handling consensus, storage, and networking.
- **Default configuration** for local testing is provided by `local_testnet_chain_config()` in the CLI crate.

## Frequently Asked Questions

### What is the first function executed when starting a Fuel Core node?

The first Rust function executed is `main` located in [`bin/fuel-core/src/main.rs`](https://github.com/FuelLabs/fuel-core/blob/main/bin/fuel-core/src/main.rs). This async function immediately awaits `cli::run_cli()`, transferring control to the command-line interface layer to handle argument parsing and service initialization.

### Which crate contains the Fuel Core binary?

The executable crate is `bin/fuel-core`. This crate depends on the core library crates but contains the standalone binary target that compiles into the `fuel-core` command-line tool used to run nodes.

### How does the node handle chain configuration on startup?

If no custom chain specification is provided, the CLI automatically invokes `local_testnet_chain_config()` and `local_testnet_reader()` from [`bin/fuel-core/src/cli.rs`](https://github.com/FuelLabs/fuel-core/blob/main/bin/fuel-core/src/cli.rs) to load the default genesis state, consensus parameters, and initial accounts suitable for local development.

### Can I programmatically start a FuelService without using the CLI?

Yes. While the binary entry point is [`main.rs`](https://github.com/FuelLabs/fuel-core/blob/main/main.rs), the `FuelService` struct exposed in [`crates/fuel-core/src/service/mod.rs`](https://github.com/FuelLabs/fuel-core/blob/main/crates/fuel-core/src/service/mod.rs) can be instantiated directly via `FuelService::new_node(...)` in Rust code. This allows embedded usage where you manage the service lifecycle programmatically rather than through the `fuel-core run` command.