📓 The password notebook that never leaves home
New here? A file .env (pronounced "dot env", short for "environment") is a plain text file that lives only on your machine and stores environment variables — name-value pairs that your automation reads when it runs, without those values being written directly into the code. This is where the passwords and access keys the automation needs are stored.
Think of a paper password notebook, the kind you keep in a drawer at home. You write down the password
for your bank, email, and Wi-Fi. Does it make sense to take this notebook with you to work? No—it stays
at home, where only you (and the people who live with you) can access it. The .env it’s exactly this notebook: it
lives on your computer and never comes along when you send the code
to repository (the “shared vault” where the code is stored and
versioned—we covered this in module 4.2; it’s GitHub).
💡 Main Concept
Code is for sharing. Secrets are for keeping. Mixing the two is the #1 mistake beginners make when they start publishing automations.
- •The code (the automation logic) can—and should—go into the repository.
- •The key that authenticates this code with another service never goes along with it.
🚪 .gitignore is the gatekeeper at the door
New here? O .gitignore is a text file inside your project that contains a list of file and folder names that the git (the program that controls what gets uploaded to the repository—module 4.2) must ignore completely. If a file is on this list, git acts as if it doesn’t exist: it never appears for upload, even if you type the wrong command and try to upload everything at once.
This is the gatekeeper standing at your front door with a list of who isn’t allowed to leave. Even if you, distracted, try to take the password notebook along with your work bag, the gatekeeper stops you at the door. The .env should always be in this list — in practice, almost every new project already comes
with this line ready, but it's worth checking.
Caption: the code and the key travel along separate paths. The code passes through the gatekeeper and reaches the repository; the key never goes there — you enter it directly in the platform’s dashboard, and only there, in the cloud, do the two meet again.
🔍 Inside
- API key: a secret code that identifies you (or your automation) to another service — like an access badge.
- Panel / dashboard: a platform’s web-based admin page, where you configure your account and automations without writing code.
🧪 Verify in practice that .env is protected
You don’t have to trust it blindly—you can check in a few steps that your .env is
actually off the send list. The goal here is simple: create a .env for example, confirm
that it’s listed in the .gitignore, and use a git command to see with your own eyes
that it doesn’t show up as something to be sent.
Objective: have a .env with placeholders (never a real key), protected by the .gitignore, and confirm this by running git status.
# conteúdo de exemplo do arquivo .env (na raiz do projeto)
API_KEY=SUA_CHAVE_AQUI
OUTRO_SERVICO_TOKEN=SEU_TOKEN_AQUI
# conteúdo do .gitignore que garante que o .env nunca suba
.env
node_modules/
dist/
# comando para checar o que o git está prestes a enviar
git status
How to verify: after running git status, the file
.env shouldn't appear in neither list — not in "modified files" nor in
"untracked files." If it appears there, that means the line .env isn't in the
.gitignore (or is misspelled)—correct it before continuing.
✓ .env in .gitignore
- ✓
git statusdoesn't list the .env - ✓Key stays only on your machine
- ✓You can share the code without worrying
✗ .env accidentally committed
- ✗
git statusshows the .env ready to send - ✗The real key is visible to anyone with access to the repository
- ✗Needs to replace the entire key later—you can’t “erase” what’s already been sent
🗂️ Adding a new key in the dashboard
New here? O Trigger.dev it’s the execution platform we mentioned in module 4.2—the service that actually runs your automation in the cloud, 24 hours a day. When your automation needs to communicate with another service (send email, read a spreadsheet, query an AI), that service’s key doesn’t go in the code: you enter it manually, once, in the Trigger.dev dashboard. See the complete end-to-end flow:
Generate the key with the service provider
Go to the website of the service you’re going to use (for example, an email or AI provider) and generate a new API key in your account settings.
Paste into the Trigger.dev dashboard, in the dev environment
In the project’s “environment variables” area, paste the key into the dev (test — topic of module 4.3) first.
Test the automation in dev
Run the automation in this test environment and check the log (the list of recorded events — we’ll return to this in module 4.7) to see whether the key is working.
Repeat in production—with a dedicated key
When you're confident, register the same variable in the environment of production — preferably by generating a second key with the provider, dedicated to production only.
🔀 Development and production have separate keys
Just as module 4.3 showed two separate “worlds” (dev and production) running the same automation, the keys follow that same separation: the Trigger.dev dashboard stores one environment variable per environment. This means the key used in your tests isn’t necessarily the same one used when the automation is actually serving real users.
✓ Key registered in the dashboard
- ✓It's stored in encrypted form by the platform itself
- ✓Changing the key is just a panel edit—no need to touch the code
- ✓Dev and production can use different keys without mixing them up
✗ Key written directly in the code
- ✗It's exposed to anyone who opens the file
- ✗Changing the key requires editing code and publishing again
- ✗Dev and production accidentally use the same key
⚠️ Attention
Never paste a real API key into a message, a shared screenshot, a chat with a coding agent asking for help to “debug,” or any public example. If you suspect a real key appeared somewhere by mistake, the next topic explains what to do — and it’s quick.
🚨 If a key leaks: the action plan
Leaks happen — what matters is responding quickly. If a real key ended up somewhere it shouldn’t (a commit by mistake, a message, a screenshot), the next step isn’t to "erase" the trace — in many cases, that isn’t enough because someone, or an automated system scanning the internet for keys, may already have copied it. The right step is to go to the service provider’s dashboard and revoke (revoke) that key, then generate a new one.
💡 Practical Tip
- •Revoke the old key with the provider — this makes it useless immediately, even if someone already has a copy.
- •Generate a new key and add it to the Trigger.dev dashboard, repeating the steps from topic 4.
- •Check whether the
.gitignoreis correct before continuing to work, so you don’t repeat the mistake.
With the secret protected, the next module (4.5) covers another kind of risk: what to do when an automation step fails midway—how to respond without duplicating anything.
Quick check (optional): where should a real API key used by your automation be stored?