🍳 The test kitchen and the open restaurant kitchen
Imagine a restaurant with two kitchens. One is closed to the public — it’s where the chef tests a new dish, overdoes the salt, throws it out, and tries again, without rushing and without anyone waiting for a meal at their table. The other is the kitchen that’s open now, with customers seated and waiting for their food. No one in their right mind tests a new recipe in the kitchen that’s serving actual customers.
New here? Production is the name for the environment that's actually "live" — the automation running for real, working with real data, sending real emails, and carrying out actions that no one can undo with "ctrl+Z." It's the open kitchen.
New here? Staging (also called an environment of dev, short for “development,” is the closed kitchen: a separate copy of the automation running with fake or test data, where you can break everything without affecting any real customers.
💡 Main Concept
The same automation running in two different places. One is safe to make mistakes in; the other isn’t.
- •Staging/dev: closed kitchen, make as many mistakes as you like.
- •Production: an open kitchen, with the customer seated and waiting for the right dish.
⚠️ Why a bug in production is more than just ugly
If a site has a small visual glitch, you fix it and no one notices. Automation is different: it acts. A bug in an automation running in production can send the same email twice to hundreds of real customers, record the same duplicate order in your system, or trigger a charge that shouldn't exist. You can't "unsend" an email that's already reached someone's inbox.
That’s why the rule is simple and has no exceptions: every code change goes through the staging/dev environment first, runs there, is reviewed, and only then — with approval — goes to production. Testing directly in production is like the chef trying out a new recipe by serving it straight to the customer at table 4.
✗ Testing in production
- ✗A logic error sends duplicate emails to real customers
- ✗A poorly designed test writes duplicate records to the real database
- ✗There’s no way to “undo” an action that’s already been carried out in the real world
✓ Test in staging
- ✓The error happens, you check the log, fix it, and test again
- ✓No real customer noticed that something broke
- ✓Only what’s already been verified as working goes to production
⚠️ Attention
A bug in production isn’t shameful—it happens to every team. The problem is not have a staging environment to catch this bug before it reaches the customer. That’s the safety net this module builds.
🔍 The two environments from the inside
In practice, "two environments" doesn't mean two physically different computers. It's the same cloud execution platform (Trigger.dev from module 4.2) running the same code twice, each with a environment variable different, marking which is which — a kind of badge that says "this is staging" or "this is production".
Caption: the same code leaves the repository and feeds both environments — what changes is the environment variable that says “I’m in dev” or “I’m in production,” and the data each one can see.
🔍 Inside
- Environment variable: information stored outside the code (like a note stuck to the dashboard) that tells the program “you’re running in dev” or “in production” — without needing to rewrite anything.
- API key separated by environment: dev uses a test key, production uses the real key — we'll go deeper into this in module 4.4 (Secrets).
✓ Correct variable for each environment
- ✓Dev reads
AMBIENTE=devand uses test data - ✓Production reads
AMBIENTE=producaoand uses real data
✗ Hardcoded value
- ✗The code always points to production, even when you just want to test
- ✗Testing becomes synonymous with risking real data because you can’t “choose” the environment
🔁 The flow of a change, from code to production
When the agent (Claude Code) changes something in your automation, that code doesn't go straight to production. It goes through a pipeline with stops — each stop is a chance to catch an error before it reaches the customer.
Code changes
The agent writes or adjusts the automation's TypeScript (remember module 4.2 — you read and approve it; you don't write it by hand).
Tested in dev
The automation runs against the staging environment with test data. You review the log and check whether the result is what you expected.
Approved
You — the person, not the agent — decide that the behavior is correct and give the green light to proceed.
Promoted to production
Only now does the same code run against production, changing real data.
💡 Main Concept
Notice that “tested” and “approved” are two separate steps: passing the test doesn’t mean it has been promoted. Promotion is always an explicit decision you make.
🛠️ Build: running the automation pointed at dev
New here? CLI it’s the abbreviation for “command-line interface”—the program you run from the terminal by typing a command instead of clicking buttons on a screen. Trigger.dev has its own CLI for running your tasks.
Objective of this task: asking the agent to run the automation explicitly pointed to the dev environment, never leaving this "on autopilot." Ask for something like: "run the notifications automation task pointing to the dev environment, not production". The command behind it usually looks something like this:
AMBIENTE=dev npx trigger.dev@latest dev --env=staging \
--api-key=<isto voce troca>SUA_CHAVE_AQUI</isto voce troca>The variable AMBIENTE=dev and the flag --env=staging ensure the automation only sees the test environment. Never paste a real API key into a prompt or shared file — always use a placeholder such as SUA_CHAVE_AQUI until it's time to actually configure it (module 4.4 explains where this key really lives).
🔍 How to verify
- 1. In the Trigger.dev dashboard, check that the run appears under the "Development"/"Staging" environment—not under "Production".
- 2. Open the log (the list of events recorded during execution, covered in more detail in module 4.7) and confirm that the data used is test data, not real data.
- 3. If the automation sends anything (email, message), make sure it went to a test inbox—never to a real customer.
🧭 Consolidate: plan mode is more valuable here than in any previous learning path
You learned about the plan mode there in module 0.5: the agent shows what it intends to do before acting, and you approve or adjust it. In none of the previous tracks did this matter as much as here — because now "doing" can mean changing production, with real customer data, and no undo button.
A practical rule to remember: whenever you ask the agent to promote a change to production, make it use plan mode first. Have it show you exactly what will change and in which environment. Read it, then say “go ahead.”
🎯 Main Concept
- •Staging is where you can make mistakes at no cost—always use it before changing production.
- •Plan mode before any promotion to production—no exceptions.
Quick check (optional): Why does an automation test in staging before going to production?