In Part 1, we explored what Dapr is and why it exists. Now it’s time to make it real. Before you can use state management, pub/sub, or any other building block, you need a smooth local development workflow, one that feels natural, fast, and familiar.

Dapr is often associated with Kubernetes and cloud deployments, but most development happens on a laptop. If Dapr doesn’t fit cleanly into your inner loop, it won’t be adopted at all. This post focuses on exactly that: running and debugging Dapr locally, using the same workflow you’d expect for any other service.

What “Running Dapr Locally” Actually Means

Running Dapr locally does not mean:

• Running Kubernetes
• Deploying to the cloud
• Learning a new development model

It means:

• Running your application as a normal process
• Running Dapr as a sidecar alongside it
• Using local infrastructure (or containers) for dependencies

Dapr was designed for fast, iterative development and that’s what we’ll focus on here.

Installing Dapr Locally

Dapr consists of two main parts:

• The Dapr CLI
• The Dapr runtime

Once the CLI is installed, initialising Dapr locally is a one‑time step:

dapr init

This sets up:

• The Dapr runtime
• A local Redis instance (used by default for state and pub/sub)
• The placement service (used only for actors)

You don’t need to understand all of these yet. The important part is: Dapr now has everything it needs to run locally.

Note: In local mode, Dapr loads components at startup and does not hot‑reload them. In Kubernetes, components can be updated dynamically.

Your First Local Dapr App

At its simplest, running an app with Dapr looks like this:

.NET example

dapr run \
  --app-id myapp \
  --app-port 8080 \
  --dapr-http-port 3500 \
  -- dotnet run

Or for Go:

Go example

dapr run \
  --app-id myapp \
  --app-port 8080 \
  --dapr-http-port 3500 \
  -- go run main.go

What’s happening here:

• Your application runs exactly as it normally would
• Dapr starts a sidecar process alongside it
• Dapr listens on port 3500
• Your app listens on its own port (e.g. 8080)

From your application’s point of view, nothing special is happening and that’s the point.

Understanding the Local Architecture

Locally, the architecture looks like this:

Your App (8080)
      ↓
Dapr Sidecar (3500)
      ↓
Local Infrastructure (Redis, etc.)

Your application:

• Receives HTTP requests as usual
• Calls Dapr via HTTP or gRPC when it needs state, pub/sub, or bindings

Dapr:

• Handles communication with infrastructure
• Manages retries, timeouts, and serialisation
• Emits logs and metrics independently

This separation is key to understanding how Dapr fits into your workflow.

Adding Components Locally

Dapr integrations are configured using components, which are simple YAML files.

Locally, components are usually placed in a components/ directory:

components/
└── statestore.yaml

When you run Dapr, you point it at this directory:

dapr run \
  --app-id myapp \
  --app-port 8080 \
  --components-path ./components \
  -- dotnet run

This mirrors how Dapr is configured in production, the same components, the same structure, just running locally.

Note: If you don’t specify a components path, Dapr uses the default directory at ~/.dapr/components.

Debugging with Dapr

This is where Dapr fits surprisingly well into normal development workflows.

Debugging the application

Your application runs as a normal process:

• Attach a debugger
• Set breakpoints
• Step through code
• Inspect variables

Nothing about Dapr changes this.

Debugging Dapr itself

Dapr runs as a separate process, with its own logs.

Useful commands include:

dapr list
dapr logs --app-id myapp

This separation makes it easier to answer an important question:

“Is this a bug in my application, or a configuration/infrastructure issue?”

Common Local Pitfalls

A few things that commonly trip people up:

Port conflicts

Dapr needs its own HTTP and gRPC ports.

Forgetting to restart Dapr

Component changes require restarting the sidecar.

Confusing app logs with Dapr logs

They are separate processes, check both.

Missing components path

If Dapr can’t find your components, integrations won’t work.

Once you understand these, local development becomes predictable and fast

Why This Matters for the Rest of the Series

Everything else in this series builds on this local setup:

• State management
• Pub/Sub
• Bindings and storage
• End‑to‑end workflows

The same dapr run workflow applies everywhere. Once you’re comfortable running and debugging Dapr locally, the rest of the building blocks feel much less intimidating.

What’s Next

Now that we can run and debug Dapr locally, we can start using it for real work.

In the next post, we’ll look at State Management with Dapr, using Redis and Postgres, all running locally, using the setup described here.