🚀 Deploy: getting off your laptop

If your automation stops working when you close your laptop, it’s not automation yet—it’s a script you trigger yourself.

This is the quickest test to see whether something is ready to become a real routine or still depends on you.

Local execution, requiring your presence, “run on its own.”

The cloud is a computer owned by another company, always on, rented by usage — your automation runs there, not in your room.

Understanding this shift in “where it runs” is the foundation for making sense of everything else in the learning path.

Remote server, 24/7 availability, pay-per-use cost.

One-off tasks that you trigger yourself ("organize this folder now") don’t need any deploy.

Publishing everything to the cloud unnecessarily creates extra work and extra cost for no reason.

One-off task vs. recurring routine.

Claude Code writes the code, git takes it to the repository (GitHub), and a hosting platform pulls and runs that code in the cloud.

This is the complete map that module 4.2 will explain step by step.

Repository, execution platform, pipeline.

The agent writes the code; your skill in this track is reading the result and the log — not writing TypeScript.

Takes away the fear that “I need to become a programmer” to publish real automations.

Reading logs, reviewing, delegating code writing.

Pipeline → dev/production → secrets → retries → hands-on build → observability.

Seeing the complete path helps you avoid getting lost in the middle of a new, technical topic.

Learning path progression, dependencies between modules.

You ask for the task in Portuguese, and the agent writes the "recipe" in TypeScript — a programming language used by these execution platforms.

Knowing this step exists (and that you don’t write it) takes away the fear of “I don’t know how to code.”

TypeScript, task (a task in code), assisted writing.

Git sends the code to the repository—an online vault (GitHub) that stores every version of your project.

It's this step that the execution platform watches: when something new arrives there, it reacts.

git, repository, push (the command that sends it).

A runtime platform (we use Trigger.dev in this course) pulls this code from the repository and runs it on its own servers, without relying on your computer.

It's the station where automation truly “comes to life on its own.”

Execution platform, deploy, cloud environment.

After it runs, the platform records everything in a log that you can monitor from the dashboard—without needing to look at the code.

It's the skill that replaces “knowing how to code”: knowing how to read this output.

Log, dashboard, execution result.

At each stage, you ask, review, and approve—the agent does the heavy lifting of writing code.

Defines exactly where your attention is needed and where you can trust the process.

Review, approval, supervised delegation.

Write → send → run → record. A short cycle that repeats with every change you approve.

Mastering this cycle is what makes you comfortable publishing any automation from here on out.

Deploy cycle, repeatability.

A copy of the automation running separately, where errors don’t affect anyone in the real world.

This is where you test changes before putting them into effect for real.

Test environment (dev/staging), isolated copy.

The environment that actually runs, handling real data and sending real things (emails, spreadsheets, messages).

Errors here have real consequences—which is why it’s important never to test directly on it.

Production environment, real data, real action.

The same code runs in both environments; what changes are the settings and secrets used in each one.

You don’t have to duplicate your work — just point to the right environment before publishing.

Same code, environment-specific configuration.

Only goes to production after running without errors in the test several times, with data similar to real data.

Avoids the shock of discovering a bug after real data has already been affected.

Promotion criterion, repeated testing.

Plan mode (introduced in module 0.5) asks the agent to show what it’s going to do before acting — here, a production bug isn’t just ugly; it costs you duplicate data.

Making this specific requirement for production changes a habit is what separates safe sessions from risky ones.

Plan mode, review before taking action, cost of errors in production.

Tested in the test environment, reviewed the plan, checked the secrets for the right environment—only then promote it.

A short checklist helps you remember the step that hurts most to forget.

Promotion checklist.

Any information that grants access to something — an API key, password, token — and must not leak to anyone.

Cloud automation always uses secrets to communicate with other services—protecting them is mandatory.

Secrets, API key, access token.

The file .env stores your secrets locally and stays out of what gets sent to the repository.

Repositories can accidentally become public—a secret leaked there is practically impossible to take back.

.env file, .gitignore (list of things that should never be uploaded).

The keys are entered directly in the execution platform’s dashboard, in a protected field—never in the code.

This is the only way for the automation to access the secret without it ever passing through the repository.

Manual setup, in a protected dashboard field.

The test secret and the production secret are set up separately — each environment has its own key.

That way, a wild test never touches the real production account or service.

Per-environment secret, credential isolation.

Rotation means generating a new key and disabling the old one — the fix for an exposed secret.

Knowing the next step keeps a scare from turning into a bigger problem.

Key rotation, revocation.

.env outside the repository, keys configured in both environments, no secrets in screenshots or messages.

A short checklist becomes a habit and helps prevent the costliest mistake on this learning path.

Secrets security checklist.

Connection drops, external service slows down, server restarts—temporary failures are normal in the cloud.

Accepting that failures will happen changes how you design the automation from the start.

Transient failure, network instability.

Retry is the platform automatically trying again to complete a step that failed, without you having to restart everything.

This is the mechanism that lets the automation recover from temporary failures without your intervention.

Retry, automatic attempt.

If the entire automation is one block, a failure halfway through means redoing everything—including the parts that already worked.

Breaking it into small steps means only the step that failed needs to be repeated.

Breaking it into steps, task granularity.

Separating the step that fetches data from the step that saves it prevents a retry from saving the same thing twice.

This is the design that prevents the most common problem with poorly planned automation: duplicate entries.

Fetch/save separation, duplicate prevention.

A queue holds pending tasks in order, processing them one at a time — like a bank line, but for work.

Queues prevent overload when many tasks arrive at once.

Queue, sequential processing.

Small tasks + automatic retries + separate fetching from writing.

This is the summary you can ask Claude Code to apply whenever you design a new automation.

Resilience, design principles.

Your first release should be small — something like emailing a daily summary.

Starting simple reduces the number of things that can go wrong during your first deployment.

Small scope, first deploy.

A clear prompt describing what the automation should do, when it should run, and what it needs access to.

The clearer the request, the fewer back-and-forths it takes to get the code right.

Task prompt, scheduling.

Run the task in the test environment with a test secret, and check the log.

It's the step that keeps an error from going straight into the real world.

Test in dev, check the log.

Repeat the secret setup, this time in the production environment, using the service’s real key.

Without this, the published automation runs in production but fails because it lacks credentials.

Production secret, configuration dashboard.

The deploy command uploads the code that has already been tested to the platform’s production environment.

This is when the automation truly comes to life, outside your computer.

Deploy, production release.

After deployment, confirm in the dashboard that the automation is scheduled, then wait for the first automatic run.

Seeing it run on its own, without you touching anything, proves that the whole workflow worked.

Schedule confirmation, first automatic run.

A dashboard is the platform's web page where you can see all the runs of your automation.

This is the only place where you can “see” what’s happening in the cloud.

Panel, dashboard, run list.

The log is the ordered list of everything the automation did — like a captain’s log.

Reading the log is the skill that replaces “knowing how to code” throughout this entire learning path.

Log, recorded event.

Failures are often highlighted in red in the log — it’s the first place to look when something goes wrong.

Avoids reading the entire log line by line when the problem is already flagged.

Highlighted error, point of failure.

Copy the log snippet with the error and paste it into a conversation with the agent, asking it to explain and fix it.

You don’t have to figure out the error on your own — you need to know where to find it and bring it to the right agent.

Assisted diagnosis, guided correction.

Many platforms send you an email when a run fails, so you don’t have to keep checking the dashboard.

This is what turns observability from a “manual task” into an “automatic habit.”

Alerts, failure notifications.

You went from “it only works on my laptop” to “it runs on its own, with protected secrets and a way to check the automation's health.”

It's the foundation for the next tracks, which assume your automation can already run in the cloud.

Deploy, observability, next track.