1. Introduction: closing the delivery cycle

Description

By the end of this lesson you will be able to describe a workflow's complete delivery cycle —edit, export, commit, test, promote, and, if needed, revert— seen end to end, as a single chain and not as loose steps. You're going to have the map of this module's eight lessons, the one closing out the guide. And you're going to learn the criterion separating a demo that works on your screen from a deployment a company can operate without you: the criterion this whole module exists to install in you.

This matters because up to here you built every piece, but you haven't yet connected them in the motion that turns them into a deliverable system. You already have the versioned repository (Modules 2 and 3), the three isolated environments running in Docker (Module 4), and a sandbox test pass you ran at zero cost (Module 5). You have the parts. What's missing is what a system owner does with them every day: taking a tested change from one environment to the next without breaking production, reviewing every change before it arrives, being able to go back when something fails, and delivering the whole package so someone else can pick it up. That's this module's work, and it's exactly what the best-paying job postings describe when they ask for workflows "as version-controlled, documented JSON."

Connection to the module: this lesson is the closing map. Here you see the complete cycle in one picture and meet the final deliverable you're going to build over the eight lessons. Lesson 2 teaches you to promote —moving a workflow from staging to prod with the CLI; lesson 3, to review every change as a diff before promoting it, including changes an AI made; lesson 4, to let an AI build workflows against a non-prod environment using n8n's MCP server, never directly on production; lesson 5, to revert with a runbook when something breaks; lesson 6, to decide between Enterprise's native Git and this guide's CLI flow; lesson 7, to set up a CI check validating the JSON on every commit and to build the portfolio artifact. Lesson 8 is the final project: the complete, defensible deliverable closing out the module and the guide.

A workflow's lifecycle, seen whole

Let's look at this module's work from above, because when you see the complete chain, every link makes sense.

Think about how a new dish reaches the menu at a large restaurant, one with several kitchens. They don't invent it directly in the kitchen serving the diners. The process is more careful, and for good reasons.

First, the chef tests the idea in the test kitchen: a separate space, with practice ingredients, where they can get it wrong without anyone getting served a bad dish. Once the recipe convinces them, they write it in the restaurant's recipe book, with the date and the reason for the change. Then it moves to the rehearsal kitchen, which mimics the real kitchen's conditions —the same oven, the same pace— to see if it holds up under pressure. Only once it's passed both kitchens, and someone with judgment reviewed the written recipe and approved it, does the recipe reach the main kitchen, the one cooking for paying customers. And if something goes wrong that night —the new recipe didn't hold up like it did in rehearsal— the head chef doesn't improvise: they pull the previous recipe from the book, the one that worked, and go back to it in minutes. The recipe book kept the good version; it never lost it.

That journey —test kitchen, recipe book, rehearsal kitchen, main kitchen, and an emergency exit backward— is, almost point for point, a professional workflow's lifecycle. Swap the names:

• The test kitchen is your dev environment: where you build and break without fear.
• The recipe book is your cumbre-automations repository: where every version lives with its date, its author, and its reason.
• The rehearsal kitchen is staging: where you test the change under conditions resembling the real thing.
• The main kitchen is prod: where Cumbre's real orders run.
• The emergency exit is the rollback: going back to the last good version the recipe book saved.

This guide's first three modules gave you the recipe book. Module 4 gave you the kitchens. Module 5 taught you to test in the test kitchen and the rehearsal one. This module teaches you the step joining it all together: how a recipe travels from one kitchen to the next in a controlled way, how it gets reviewed before serving, and how it gets undone if it goes wrong. That journey has a technical name, and it's the word governing this module: promotion.

The complete pipeline

Let's put the chain in one picture, because you're going to have the six modules condensed here, in your head. This is the journey a change takes, from idea to production and, if needed, back:

  edit          export        commit        test          promote        revert
    │              │             │             │              │              │
  in dev    →   with the   →   to Git   →   in sandbox  →   to staging  →  to the
 (or with AI       CLI to        (recipe      and staging     and to prod    last good
  via MCP)      normalized JSON  book)        (Module 5)      (this module)  JSON (this
    │              │             │             │              │              module)
 Module 4     Modules 2-3    Modules 2-3    Module 5      Module 6        Module 6

Read it left to right as the happy path —a change born in dev, versioned, tested, and reaching prod— and right to left as the safety net —when something fails in prod, you go back to the repo's last good JSON. You already know how to do the first four columns. The last two, promoting and reverting, are this module's heart.

Notice a detail in the first column: it says "edit in dev, or with AI via MCP." That's a novelty in this module you might not have expected. n8n 2.0 lets an AI assistant —Claude, ChatGPT, Cursor— build and edit workflows inside your instance, through a technology called MCP. It's powerful and dangerous at the same time, and that's why lessons 3 and 4 devote full attention to it: AI can build, but never directly in production. It builds in dev, Git records the change, a human reviews it, and only then does it get promoted. The isolated environments you set up in Module 4 are precisely the net making it safe to let an AI touch your workflows.

Worked example: an order-triage change, from idea to production

Let's follow a concrete change through the whole pipeline, so the chain stops being abstract. We're not going to run commands —that's for the lessons that follow— we're going to see the journey, so when you learn each link separately you know where it fits.

The change: Cumbre's team decides orders over 5000 pesos should no longer get auto-approved, but go to manual review instead. A small new business rule, touching order-triage. Let's see its journey.

It's born in dev (edit). Someone —a person in the editor, or an AI via MCP pointed at dev— adds the threshold and the manual-review step in the development environment. Here it gets tested by hand, breaks, gets adjusted. None of this touches production: dev uses synthetic data and test credentials, so getting it wrong costs nothing. What to expect: the modified workflow runs in dev and does the new thing.

It gets versioned (export and commit). The change gets exported with the CLI into a normalized JSON and committed to cumbre-automations with a clear note: "send orders over 5000 to manual review." Now the change exists in the recipe book, with its date and its reason. What to expect: a new commit in the history; git diff shows only the threshold's and the review node's lines, nothing more.

It gets tested (in sandbox and in staging). The change gets promoted to staging and Module 5's test pass gets run: synthetic data, dry run, assertions. It gets confirmed that orders over 5000 land in manual review and the rest follow their course. What to expect: the pass comes out green; the change earned its way to production.

It gets reviewed (the diff, before promoting). Before touching prod, a human reads the diff one last time: does it do what it says? did something unexpected change? did a secret slip in? The diff is boring in the good sense —just the threshold— so it gets approved. What to expect: an approved pull request, with a record of who and when.

It gets promoted (to prod). The reviewed JSON gets imported into the prod instance, arrives inactive, gets verified that the real credentials resolve, and gets activated by hand, watching closely. What to expect: order-triage starts processing Cumbre's real orders with the new rule.

And if something fails (revert). Suppose that, already in prod, an effect shows up that staging never reproduced. The rollback runbook goes back to the repo's last good JSON and re-imports it in minutes. What to expect: prod running the version that worked again, while the problematic change waits in dev to be debugged calmly.

Notice what this journey has that a demo doesn't: at every link there was a net —a test, a review, an emergency exit. The change didn't jump from someone's head to production; it traveled a chain of trust where each step earned the next. That complete journey is what this module teaches you to execute, link by link.

What separates a demo from a deployment

Before getting into the technique, it's worth naming the criterion this module chases, because it's the one an interviewer uses to know which side of the line you're on.

A demo is a workflow that works when you run it, on your machine, watching it. It's a real skill —building something that works isn't small— but it's fragile in a specific way: it depends on you, on the moment, and on nothing changing. If asked "so how do you take this to production?", the demo has no answer.

A deployment is the same workflow, but wrapped in the guarantees making it operable by others and recoverable when it fails. The difference isn't in what the workflow does; it's in everything surrounding it. A deployment answers, without hesitating, five questions a demo leaves hanging:

1. How does a change reach production? Not "I edit it in prod," but "I test it in dev, verify it in staging, and promote it to prod with a repeatable procedure." That's lesson 2.
2. Who reviewed this change before it arrived? Not "I looked at it," but "there's a diff someone approved, and there's a record of who and when." That's lesson 3.
3. If an AI touched the workflow, how do you know it didn't break anything? Not "I trust the AI," but "the AI only touches dev, and its change goes through the same diff and the same human review as any other." That's lesson 4.
4. If the change breaks production, how fast do you go back? Not "I try to remember what I touched," but "I follow the runbook: I go back to the repo's last good JSON and re-import it, in minutes, with steps someone else could also follow." That's lesson 5.
5. How do you guarantee the delivered JSON is well-formed? Not "I eyeballed it," but "an automatic check validates the JSON on every commit, with nobody having to remember." That's lesson 7.

Each of those questions is a lesson in this module. And each answer is a design decision you're going to be able to point to in your own repository at the end. That's the point: at the end of this module you're not going to say you know how to deliver like a professional; you're going to have the artifact proving it.

The final deliverable you're going to build

This module closes out the guide, so it's worth seeing right away where everything's pointing. Lesson 8's project isn't a new exercise: it's the integration of the six modules into one deliverable, packaged exactly as the market asks for. When you finish, you're going to have a GitHub repository —cumbre-automations— containing:

• The order-triage workflow exported via CLI, normalized for clean diffs and documented with a handoff README, with credentials out of the repo (Modules 2 and 3).
• Three environments isolated by Docker Compose —dev, staging, prod— each with its own N8N_ENCRYPTION_KEY and its test or production credentials (Module 4).
• A sandbox test pass executed at zero cost: synthetic data, sandbox keys, dry run, execution replay, and assertions with the Evaluation node using local models (Module 5).
• A promotion and rollback runbook: the numbered steps for bringing a change to production and for reverting it under pressure (lessons 2 and 5 of this module).
• A CI check in GitHub Actions validating the workflow's JSON on every commit, at zero cost (lesson 7).

That package is the portfolio artifact. It's defensible in an interview, it works as proof you don't just build workflows but version, test, promote, and operate them, and it gets produced entirely without paying a subscription —the only account you open is GitHub's, which is free for a repository like this. This guide's whole default path is self-hosted Community at zero cost, and this module is no exception.

Keep that list, because lesson 8 builds it phase by phase. Everything you learn in lessons 2 through 7 is a piece of that deliverable.

The artifact grows with you, lesson by lesson

It's worth seeing the deliverable not as something appearing suddenly in lesson 8, but as something you've been building since Module 1 without realizing it. Every module added a layer, and this module adds the last one —the operational one— which is exactly the one answering the toughest interview questions.

Think of it as a house built in stages. Modules 2 and 3 laid the foundation and the walls: the versioned, documented repository. Module 4 installed the separate rooms: the three isolated environments. Module 5 tested that the plumbing doesn't leak: the sandbox pass. And this module puts in what makes the house livable by others: the instructions for how to operate it (the promotion runbook), what to do in an emergency (the rollback runbook), and the alarm watching on its own (the CI check). A house without that last layer looks finished, but nobody besides its builder knows how to live in it. With the operational layer, anyone can take it over.

This has a practical consequence for how you read the module: you aren't starting a new project, you're finishing the one you've been building the whole guide. From here on, every lesson isn't a standalone technique; it's a piece fitting into a deliverable that already half-exists. When in lesson 5 you write the rollback runbook, you're not writing it into a void: you're writing it for your cumbre-automations, the same one you documented in Module 3 and deployed in Module 4. That continuity is deliberate, and it's what makes the final project feel like a natural close instead of a surprise exam.

Where you're standing now

It's worth placing yourself precisely, because this module assumes a specific starting point, and building on it is what makes it possible.

At this point in the guide, you already have —or you're following Cumbre's case as if you had:

What you already have	Which module it comes from	Why you need it here
The versioned cumbre-automations repository	Modules 2 and 3	It's the source of truth you promote from and go back to when reverting
The normalized, documented order-triage workflow	Module 3	It's what you're going to promote, review, and, if needed, revert
Three dev/staging/prod environments isolated by Docker	Module 4	They're the "kitchens" you promote between; without them there's nowhere to promote to
Credentials per environment (test vs. production)	Module 4	When promoting, you have to map the destination environment's credentials
An executed sandbox test pass	Module 5	It's what validates a change before you promote it to prod

If you're missing any of those pieces because you skipped a module, this is the moment to go back and complete it, because this module uses it as its foundation. If you've been following the guide in order, you already have everything you need: only the delivery motion connecting it all is missing.

Notice the table's middle column: each piece comes from a different module, and none is optional for what follows. Promoting (lesson 2) makes no sense without two environments to move the workflow between —that's why you need Module 4's three environments. Reverting (lesson 5) isn't possible without a repository with history to go back to —that's why you need Modules 2 and 3's versioning. And promoting honestly requires having tested beforehand —that's why you need Module 5's sandbox pass. The module you're starting doesn't add new foundations; it builds the top floor on top of the ones you already raised. That dependency is why this is module 6 and not module 2: it only makes sense once everything else is already in place.

An honest note, as throughout the guide: if you don't have an instance handy to run the commands, read the lessons anyway. The sequence and its logic come through just the same, and you run them once you have the environment set up. What transfers —the order of the steps, each decision's reasoning— is worth more than typing the commands once.

This module's map

This is the journey of the eight lessons, with what each one solves:

Lesson	What it solves
2	Promoting with the CLI: import:workflow and import:credentials to bring order-triage up from staging to prod, mapping the destination's credentials, and deciding whether the workflow arrives active or inactive
3	Reviewing the change as a diff before promoting it: the pull request as a mandatory checkpoint, and how to review what an AI modified inside your instance
4	Building with AI against a non-prod environment: n8n's MCP server, the safe loop (the AI proposes in dev, Git records it, the human approves, it gets promoted), and why isolated environments are the net
5	Reverting with a runbook: going back to the repo's last good JSON and re-importing it, and writing the numbered procedure someone else could follow under pressure
6	Deciding between Enterprise's native Git and this guide's CLI flow, with a matrix by team size, budget, and compliance
7	Automating the review with a CI check in GitHub Actions validating the JSON on every commit, and building the defensible portfolio artifact
8	Integrating everything: the final project, the complete "version-controlled, documented JSON" deliverable, closing the module and the guide

Notice the order, because it tells a story. First forward motion —promoting (2). Then that motion's quality control —reviewing (3) and AI's special case (4). Then the safety net —reverting (5). Next the economic decision —free or paid (6)— and automating the review —CI (7). And at the end, everything together in one deliverable (8). It's the complete arc of "workflow builder" to "system owner," closing.

One last thing before starting, about pace. This module closes out the guide, so the temptation is to rush through it to "just be done." Resist that hurry. Every lesson installs an operational piece you're going to use in your real work —promoting without breaking, reverting under pressure, reviewing what an AI does— and those pieces are learned best slowly, hands on the keyboard if you have an instance, or following the reasoning carefully if you don't. There's no prize for reaching the end fast; the prize is having the deliverable done and understood. Go at whatever pace lets you be able to do each thing, not just recognize it.

Common mistakes

Believing "promoting" is simply re-exporting and re-importing (conceptual). What happens: someone reads that promoting is done with import:workflow and concludes it's just running a command, with no special care. They then import a workflow into prod and it breaks, because the destination's credentials weren't mapped or because it arrived active when it should have arrived inactive. Why it happens: the command is simple, but what surrounds it —reviewing beforehand, mapping credentials, deciding the activation state, having the rollback ready— is what makes the promotion safe. How to spot it: if your plan for bringing a change to prod is "I import it and that's it," you're missing everything surrounding the command. How to fix it: understand that promotion is a procedure, not a command. Lessons 2 through 5 are, together, that procedure: promoting, reviewing, and having a way back.

Letting an AI build workflows directly in production (conceptual and security). What happens: someone discovers they can ask Claude or Cursor to build a workflow inside their instance via MCP, gets excited, and points it at their prod instance. The AI builds, validates, and runs —sometimes against real data— without a human having reviewed the result. Why it happens: the convenience is enormous and so is the temptation to skip the steps; the AI's loop self-corrects and gives a false sense that it doesn't need supervision. How to spot it: if your AI assistant is connected to the instance where Cumbre's real orders run, you have the problem. How to fix it: the AI builds in dev, never in prod; its change goes through Git and a human review before getting promoted. It's all of lesson 4, and the principle is non-negotiable: the AI proposes, the human approves, and only then does the change reach production.

Thinking rollback gets improvised at the moment of the incident (conceptual). What happens: someone trusts that, if something breaks in prod, they'll figure out how to go back when it happens. And when it happens —at three in the morning, with complaints coming in— they don't remember which commit was the good one, nor the exact command to re-import, and lose an hour under pressure doing what a rehearsed procedure would take two minutes. Why it happens: rollback feels hypothetical until it isn't, and nobody rehearses the emergency exit while everything's working. How to spot it: if you don't have written down, anywhere, "to revert order-triage I do exactly these steps," you don't have a rollback, you have a hope. How to fix it: write the runbook before you need it and rehearse it once, calmly. It's lesson 5, and its motto sums up the module: you rehearse the rollback before the incident, not during.

Exercises

Exercise 1 — Draw your own pipeline. Without looking back at this lesson's diagram, draw from memory a workflow change's lifecycle, from idea to production and back. Mark at each link which guide module taught you that piece. Then compare against the "A workflow's lifecycle, seen whole" section's diagram and note which link you missed.

See solution

The pipeline is: edit (in dev, or with AI via MCP — Module 4) → export (with the CLI, into normalized JSON — Modules 2 and 3) → commit (to the repository — Modules 2 and 3) → test (in sandbox and in staging — Module 5) → promote (to staging and to prod — Module 6) → and, if needed, revert (to the last good JSON — Module 6).

What most people draw well is the middle part —export, commit, test— because they're the modules just finished. What gets missed most are the two ends: that editing can come from an AI (lesson 4's hook) and that rollback is a first-class link, not an accident (lesson 5).

Why it works: having the complete pipeline in your head is what lets you place any technique from the module in its spot. When in lesson 2 you learn import:workflow, you're not going to see it as "another command," but as the cycle's "promote" link you already drew. The map gives every piece a place.

Exercise 2 — Demo or deployment. For each situation, say whether it describes a demo or a deployment, and what the demo is missing to become a deployment: (a) "I built the workflow, ran it, it worked, and I sent the client the link." (b) "The workflow is in prod, there's a runbook to revert it, and every change went through staging and a diff review." (c) "I asked Cursor to build the workflow on my instance and it's already running with real data."

See solution

(a) Demo. It works when the author runs it, but doesn't answer how a change reaches production, who reviews it, or how it gets reverted. To become a deployment it's missing this whole module's cycle: environments, controlled promotion, diff review, and rollback.

(b) Deployment. It answers the questions a demo leaves hanging: how the change arrives (through staging), who reviewed it (the approved diff), and how it gets reverted (the runbook). It's exactly what this module builds.

(c) Dangerous demo. It's worse than (a), because it's not just missing the cycle, it breaks lesson 4's principle: an AI building directly in production, against real data, with no human review. To become a deployment it would have to point the AI at dev, run the change through a reviewed diff, and only then promote it to prod.

Why it works: the "demo versus deployment" criterion is the same one an interviewer uses, even if they don't say it in those words. When they ask "how do you handle deployments?", they're measuring whether your work ends at the demo or whether you know how to wrap it in a deployment's guarantees. This exercise trains you to hear that question behind its many forms.

Exercise 3 — Inventory your starting point. Go through the "Where you're standing now" section's table and, for Cumbre's case (or for your own project if you have one), check off which of the five pieces you already have ready and which you don't. For each missing piece, write in one sentence which module you'd have to go back to.

See solution

There's no single answer; the result is your diagnosis. If you've been following the guide in order, you should be able to check off all five: versioned repository, normalized and documented workflow, three isolated environments, credentials per environment, and an executed sandbox test pass.

If you're missing any, the table tells you exactly where to go back: the repository and the normalized workflow are Modules 2 and 3; the environments and per-environment credentials are Module 4; the test pass is Module 5. This module builds on those five pieces, so a gap here is going to be felt in the lessons that follow.

Why it works: a system owner starts any work by checking their starting point, not assuming it. This inventory is that habit in small. And it saves you the frustration of trying to promote a workflow (lesson 2) when you're actually missing the second environment to promote it to (Module 4).

Summary and next step

In this lesson you saw a workflow's complete lifecycle —edit, export, commit, test, promote, revert— as a single chain, with the image of a restaurant's kitchens: the test kitchen (dev), the recipe book (cumbre-automations), the rehearsal kitchen (staging), the main one (prod), and the emergency exit (the rollback). You understood this module closes out the guide by teaching the motion joining every piece you already have: controlled promotion between environments, reviewing every change as a diff (including ones an AI makes), building with AI against non-prod environments via MCP, rollback with a runbook, the decision between native Git and the CLI flow, and the CI check validating the JSON on every commit. You saw the criterion separating a demo from a deployment —five questions a deployment answers and a demo leaves hanging— and met the final deliverable you're going to build: the complete portfolio artifact, at zero cost.

Before moving on to lesson 2 you should be able to: draw the complete pipeline from memory and place each module at its link; explain in one sentence what separates a demo from a deployment; and say which five pieces you already have from previous modules and why this module needs them.

What follows is starting to move. Lesson 2 dives right into promotion: you're going to take order-triage, already tested in sandbox, and bring it from staging to prod with n8n's CLI. You're going to meet import:workflow and import:credentials, the problem of mapping the destination environment's credentials, the decision of whether the workflow arrives active or inactive, and —most important— what to check before promoting so you don't break Cumbre's real orders. It's the first of the two missing links, and the one turning your repository into something that really reaches production.

Resources

• Source control and environments — n8n Docs — the official section on version control and environments; the framework where everything this module does by hand in Community lives.
• Use the command line — n8n Docs — the CLI reference, including import:workflow and import:credentials, which lesson 2 uses to promote.
• Set up and use the n8n MCP server — n8n Docs — the instance-level MCP server letting an AI build workflows; the foundation for lessons 3 and 4. Check its status and exact location on your version.
• GitHub Actions documentation — GitHub Docs — the free CI platform lesson 7 uses to validate the JSON on every commit.
• Release notes 2.x — n8n Docs — n8n's version 2 history; useful for confirming which version you're using against what this module says, especially for MCP features, which evolve fast.