In Part 4, we explored how Dapr simplifies event‑driven communication through its pub/sub building block. Now we’ll look at another common integration point in distributed systems: external services such as object storage, queues, SaaS APIs, and cloud‑native capabilities.

Traditionally, integrating with these systems means importing vendor‑specific SDKs, managing credentials, handling retries, and writing environment‑specific configuration. Dapr’s bindings building block provides a consistent way to interact with external systems using simple HTTP or gRPC calls, no vendor-specific SDKs required.

This post focuses on how bindings work, how to use them for storage, and why they’re a powerful tool for keeping infrastructure concerns out of your application code.

What Are Dapr Bindings?

Bindings allow applications to:

• Invoke external systems (output bindings)
• Be triggered by external systems (input bindings)

From the application’s perspective, bindings are just HTTP or gRPC calls. Dapr handles the integration with the external service.

Bindings are commonly used for:

• Object storage (S3, Azure Blob Storage)
• Queues and streams
• Webhooks and SaaS APIs
• File systems and cloud services

They’re especially useful when you want to avoid pulling cloud‑specific SDKs into your codebase.

Note: Bindings intentionally expose only a subset of provider operations, typically create, get, delete, or provider‑specific equivalents. They are not full SDK replacements.

Storage as a Binding

Object storage is a great example of where bindings shine. Many applications need to:

• Upload a file
• Download a file
• Delete a file

They don’t need to know:

• Which cloud provider is being used
• How authentication works
• How retries or timeouts are handled
• How provider‑specific APIs differ

Dapr lets you treat storage as an external capability, configured outside your application.

Architecture Overview

At runtime, storage access looks like this:

Application → Dapr Binding API → Storage Provider (S3 / Azure Blob / local)

The application talks only to the local Dapr sidecar. Dapr handles the provider‑specific integration, authentication, retries, and serialisation.

Configuring a Storage Binding

Bindings are defined using Dapr components.

Example: Azure Blob Storage binding

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: storage
spec:
  type: bindings.azure.blobstorage
  version: v1
  metadata:
    - name: accountName
      value: myaccount
    - name: accountKey
      value: mykey
    - name: containerName
      value: uploads

A few important notes:

• The component name (storage) is what applications reference
• Secrets should be stored in a secret store component, not inline (shown inline here just for example)
• You can restrict bindings to specific apps using scopes:
• In local mode, components load at startup (no hot‑reload)
• In Kubernetes, components can be updated dynamically

Writing to Storage Using Dapr

Go example: uploading a file

package main

import (
	"context"
	"encoding/json"
	"fmt"

	"github.com/dapr/go-sdk/client"
)

type Order struct {
	Id string `json:"id"`
	Amount  int    `json:"amount"`
}

func main() {
	ctx := context.Background()
	daprClient, _ := client.NewClient()
	order := Order{Id: "order-123", Amount: 100}
	saveOrder(ctx, daprClient, order)

    storeReceipt(ctx, daprClient, order)
}

func storeReceipt(ctx context.Context, daprClient client.Client, order Order) error {
	data := []byte("Order receipt for " + order.OrderID)
	req := &client.InvokeBindingRequest{
		Name:      "storage",
		Operation: "create",
		Data:      data,
		Metadata: map[string]string{
			"blobName": order.Id + ".txt",
			"key":      order.Id + ".txt",
			"fileName": order.Id + ".txt",
		},
	}

	_, err := daprClient.InvokeBinding(ctx, req)
	return err
}

There is no Cloud Specific SDK, no credentials in code, and no storage‑specific logic.

.NET example: uploading a file

var client = new DaprClientBuilder().Build();

var order = new Order("order-123",100);

var metadata = new Dictionary<string, string>
{
     ["blobName"] = $"{order.Id}.txt",
     ["key"] = $"{order.Id}.txt",
     ["fileName"] = $"{order.Id}.txt"
};

await client.InvokeBindingAsync(
    "storage",
    "create",
    Encoding.UTF8.GetBytes($"Order receipt for {order.Id}"),
    metadata
);

The same code works regardless of whether the backing store is Azure Blob Storage or S3.

Switching to S3 Without Code Changes

To switch from Azure Blob Storage to S3, only the component configuration changes.

Example: AWS S3 binding

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: storage
spec:
  type: bindings.aws.s3
  version: v1
  metadata:
    - name: bucket
      value: my-bucket
    - name: region
      value: eu-west-1
    - name: endpoint
      value: s3.eu-west-1.amazonaws.com
    - name: accessKey
      value: mykey
    - name: secretKey
      value: <add secret key>

Note: Secrets should be stored in a secret store component, not inline (shown inline here just for example)

The application code remains unchanged.

This makes it easy to:

• Use local or cloud‑specific storage per environment
• Migrate between providers
• Keep application logic provider‑agnostic

Input Bindings: Triggering Applications

Bindings can also trigger applications.

For example:

• A file uploaded to storage
• A message arriving on a queue
• An event from a SaaS system

Dapr delivers these events to your application as HTTP requests, allowing you to react without polling or SDKs.

A few nuances:

• Input bindings follow at‑least‑once delivery semantics
• Your app acknowledges processing by returning a 200‑level response
• Dapr handles retries and backoff
• Observability is automatic
• Events are delivered as CloudEvents

This is particularly useful for building event‑driven workflows around storage and integration points.

Why This Matters in Practice

Using Dapr bindings for storage and integrations enables:

• SDK‑free integrations – No cloud‑specific libraries in application code.
• Infrastructure portability – Switch providers via configuration.
• Cleaner security boundaries – Credentials live in components, not code.
• Simpler local development – Use local or mocked services without code changes.
• Consistent patterns across languages

Bindings help teams avoid the “SDK sprawl” that often creeps into distributed systems.

Trade‑offs to Consider

Bindings are intentionally generic. They work best for:

• Simple operations (create, read, delete)
• Event‑driven workflows
• Integration points at system boundaries

They are not ideal for:

• Complex provider‑specific features
• High‑performance bulk operations
• Advanced querying or filtering
• Deep control over provider‑specific behaviour

In practice, many teams use bindings for integration and SDKs only where deeper control is required.

What’s Next

At this point, we’ve covered the core Dapr building blocks most teams adopt first:

• State management
• Pub/Sub
• Bindings and storage

In the next post, we’ll explore Observability with Dapr, including:

• What signals Dapr emits by default
• How tracing and metrics work across building blocks
• Why observability is already present, even if you haven’t configured anything explicitly

By the time you reach production, these signals are often the difference between guessing and knowing.