An automation that only runs when you click a button on your own laptop is still a prototype. To be useful it has to run all day, survive restarts, and tell you when something goes wrong. This module covers the last step between building a workflow and relying on it: putting it somewhere it can run, and keeping an eye on it once it does.
You will start with deployment. That means running your automation platform on your own machine or on a server, keeping its data in a persistent volume so workflows and credentials survive an update, and choosing between local hosting for testing and a VPS for something that must always be on. Then comes monitoring: an error workflow that catches failed runs in one place, logs them, and sends an alert so you hear about a failure before a customer does.
Workflows that call a language model need one more layer. A run can finish successfully and still return a wrong or expensive answer, so you will look at LLM observability: recording each prompt, response, token count and cost as a trace you can inspect later. Watch the lessons in order, then put everything together in the Projects section.
GrowwStacks installs n8n through the Docker Desktop interface with no terminal commands, explains why a persistent volume keeps your workflows safe, and compares running locally with renting a VPS for always-on use.
Techno Tim sets up n8n on Linux with Docker Compose, a PostgreSQL database and a .env file, then builds a few workflows on top. This is the closer-to-production setup to follow once you have seen the basics.
GrowwStacks builds one error workflow that starts with the Error Trigger node, logs each failure to Google Sheets, sends a Slack alert, and is then linked to your other workflows from their settings.
A walkthrough from Langfuse of an open-source platform for tracing and monitoring language model applications. It shows how traces capture prompts, responses, cost and latency, and how that data feeds prompt management and evaluation.