Illustrative — three configuration layers feed the workflow, which produces its first run.
🧰 n8n or Make — the choice
The first decision in building is which platform will host your workflows. You don't need both—you need to master one. The candidates are n8n (open-source, self-hosted or cloud, with an escape hatch for code) and Make (no-code, 100% hosted, quick to get started).
✓ Choose n8n when
- ✓You want to control your data (self-host) and avoid per-operation charges.
- ✓Needs complex logic: Code node in JS/Python when visual tools aren't enough.
- ✓High volume of executions—predictable cost per instance, not per step.
- ✓You want to version the workflow as JSON and take it from one client to another.
✗ Avoid starting with Make if
- ✗It will run tens of thousands of operations/month—the cost per operation will skyrocket.
- ✗Needs on-premise data for compliance — Make is cloud-only.
- ✗You want logic beyond no-code; custom code is more limited.
- ✗You want to avoid lock-in — exporting/porting is easier in n8n.
💡 Practical tip
Start with n8n cloud (trial) to learn without installing anything. When the workflow proves its value and volume grows, migrate to self-host (Docker) — the same flow JSON imports directly. Learn the tool, then optimize the hosting.
You control costs and data
Zero infrastructure, pay a subscription
Escape to complex logic
Flow portability
👤 Accounts and credentials
A credential stores access to a service once and reuses it in every node that connects to it. You set up the Gmail, OpenAI, or Supabase connection once; each node just points to it.
🔗 Dedicated service account
Never connect your personal account. Create a service account just for the automation (e.g., automacao@empresa.com). This way, you revoke access without affecting anyone and know exactly what the automation touched.
- •Minimum permissions—only the scopes the flow actually uses.
- •OAuth when the service supports it (the token expires and renews); API key when it doesn't.
- •Name the credential by environment: OpenAI · prod vs OpenAI · staging.
Format by service
When to use each one
Least privilege
Don’t use your personal one
🔑 API keys and environment variables
Everything that changes between dev and production — keys, URLs, spreadsheet IDs — lives in environment variables, outside the nodes. In self-hosted setups, this is a .env; in the flow you read with $env.
OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxxxxxx SUPABASE_URL=https://abcd.supabase.co SUPABASE_SERVICE_KEY=eyJhbGciOi... SLACK_ALERT_WEBHOOK=https://hooks.slack.com/services/... ENVIRONMENT=production
// no campo de header de um HTTP Request node: Authorization: Bearer ={{ $env.OPENAI_API_KEY }} // escolher comportamento por ambiente: ={{ $env.ENVIRONMENT === 'production' ? 'real' : 'sandbox' }}
💡 Practical tip
Keep a .env.example versioned, with the keys without value. That way, anyone (including you three months from now) knows which variables the flow needs, without ever exposing the actual secret.
🔒 Security and secrets management
The costliest beginner mistake is leak a key. An LLM key exposed on GitHub can turn into a bill worth thousands of reais within hours, because bots scan public repositories for them.
⚠️ Where secrets leak (and how to prevent it)
- ✗Pasting the key into a node’s body instead of using credential/$env.
- ✗Log the entire request object (which includes the Authorization header).
- ✗Accidentally return sensitive data in the webhook response.
- ✗Commit the .env — always in the .gitignore.
✓ Safe practices
- ✓Rotate keys periodically and at the first sign of a leak.
- ✓Least privilege: the key can only do what the workflow needs.
- ✓Mask data in logs (sk-***).
- ✓Use a secret manager as the operation grows.
✗ Dangerous habits
- ✗A single "admin" key for everything.
- ✗Send a screenshot of the workflow with the key visible in the chat.
- ✗Reuse the same key in staging and production.
- ✗Never revoke keys from former projects.
🧩 Workflow structure
A workflow is a node graph connected by connections. Each connection carries a list of items in JSON. Internalize this: everything is a list of items flowing from node to node — this is the mental model that unlocks everything else in the learning path.
Trigger
Where the flow starts
A special node that starts the execution: manual, webhook, schedule, or external event. Every workflow has exactly one starting point.
Action nodes
What does the work
Each node receives items, transforms them, and returns items. HTTP Request, Set, IF, code, Gmail — they all follow the input-item / output-item pattern.
Items and $json
The data in transit
Inside any node, $json is the current item. If the input has 50 items, the node runs 50 times (once per item) — automatically.
{
"json": {
"nome": "Ana Souza",
"email": "ana@empresa.com",
"valor": 1290.50
}
}
// no próximo node, acessa com: ={{ $json.email }}
👋 First "hello world"
Proof that the environment works: a Manual Trigger connected to a node that defines a field. You run it, see the data appear in the first node and arrive at the second. Simple — and it eliminates 90% of the anxiety of getting started.
Add a Manual Trigger
On the blank canvas, click “+” and search for Manual Trigger. It's the "Test workflow" button.
Connect it to an Edit Fields (Set) node
Create a field message with a value Hello World. Connect the trigger's output to the Set node's input.
Run it and read the output
Click "Test workflow." Open the Set node and look at the output item—your first data flowing end to end.
[
{ "mensagem": "Hello World", "executadoEm": "={{ $now }}" }
]
💡 Practical tip
Before any real workflow, always start with a "hello world" of the integration you’ll use (1 API call, 1 spreadsheet row). Proving the connection in isolation saves hours of debugging later.
📌 Module Summary
Next Module:
4.2 - First end-to-end automation (from trigger to action, with AI in the middle)