Module 7 takes the agent you built in Module 6 and turns it into a production cloud service. You'll containerize the stack, orchestrate it on Kubernetes, automate delivery, and operate it with observability, security, and cost controls. The goal: a reliable Digital FTE that runs 24/7 for real users.
Prerequisites: Modules 4-6. You need a working agent service to deploy.
Your Task API runs inside Kubernetes. But the real world doesn't live in your cluster. Customers send webhook callbacks. Scheduled jobs need to run at midnight. Messages arrive in external queues. Files appear in cloud storage. How does your Dapr application respond to these external events---and how does it send data back out?
This is where bindings come in. Unlike pub/sub (which connects your microservices to each other), bindings connect your application to external systems. An input binding lets external events trigger your code. An output binding lets your code invoke external systems.
In earlier lessons, you used pub/sub to connect your Task API to a notification service. Both were Dapr applications. Now you'll connect to the outside world: a cron scheduler that triggers cleanup jobs, an HTTP webhook that notifies external monitoring systems, a queue that receives messages from legacy systems.
An input binding makes Dapr call your application when something happens in an external system.
Think of it like a doorbell. When someone presses the button (external event), a signal rings inside your house (your application). You didn't poll for visitors. You didn't check the door every 5 seconds. The event came to you.
The simplest input binding is a cron schedule. Dapr calls your endpoint on a schedule---no external infrastructure required.
Component YAML:
FastAPI Endpoint:
Output:
Key points:
An output binding lets your code invoke external systems through Dapr's unified API.
Think of it like a universal translator. You speak one language (Dapr's binding API), and it translates to whatever the external system expects---HTTP, AMQP, S3 API, email SMTP.
A common use case: calling an external webhook when something happens in your system.
Component YAML:
Python Code:
Output:
Different binding types support different operations:
Here's how output bindings fit into a real workflow:
Output:
This is the question that trips up newcomers: "I can send messages with pub/sub AND with bindings. What's the difference?"
Ask yourself: "Is the other end a Dapr application?"
You may have noticed direction in the component YAML. This field specifies whether a binding is input, output, or both.
Most bindings default to one direction. The HTTP binding, for example, defaults to output. The cron binding is always input (you can't "invoke" a cron schedule).
When bindings don't work, check these common issues:
Check Dapr sidecar logs:
You built a dapr-deployment skill in earlier lessons. Test and improve it based on what you learned.
Does your skill generate correct component YAML with the direction metadata?
Ask yourself:
If you found gaps:
Prompt 1: Create a Cron Binding
What you're learning: Input bindings connect external triggers to your code. The cron binding is the simplest example---no external infrastructure, just time-based triggers. Pay attention to the naming convention: endpoint path must match component name.
Prompt 2: HTTP Output Binding
What you're learning: Output bindings abstract away external HTTP calls. Instead of managing HTTP clients, retries, and error handling, you configure once and invoke through Dapr's unified API. The invoke_binding method is your interface to any external system.
Prompt 3: Bindings vs Pub/Sub Decision
What you're learning: The key distinction is internal vs external. Pub/sub connects your Dapr microservices. Bindings connect to the outside world. This prompt helps you internalize the decision framework and apply it consistently.
Safety Note: When configuring bindings that receive webhooks, validate the source. Add authentication (API keys, signatures) to prevent malicious actors from triggering your endpoints. Check the Dapr documentation for your specific binding type's security options.