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.
Coding With Taz 