When you build with AI, it helps to know one basic question: where is this actually running?

Sometimes the answer is your laptop. Sometimes it is a remote server. Often it is both.

This distinction is the bridge between your personal workspace and the Infrastructure lessons later in the course. You do not need to become a cloud engineer now. You only need a clear mental model so you know what you are asking an agent to touch.

Local means your computer

Your local machine is the Mac or Windows computer in front of you. Files in your Desktop, Documents, or project folder are local. A development server you start from Terminal is usually local too.

For example, an AI might create a small website in a folder on your Mac, then run it at an address such as:

http://localhost:4321

localhost means “this computer.” Nobody else can visit that address from the public internet unless you deliberately expose it.

Local work is where you should usually begin:

• drafting Markdown files and specifications
• trying an idea safely
• building an early version of an app
• reading and editing JSON
• running tests
• reviewing AI changes before sharing them

Cloud means someone else's computer, rented for your use

The cloud is a remote computer or managed service accessed through the internet. You may use it for a website, database, authentication, file storage, scheduled job, or AI API.

Examples include a site hosted on Vercel, a database hosted on Supabase, a server at a cloud provider, or files stored in S3-compatible storage. The cloud is not magic. It is just computer infrastructure that stays on when your laptop is closed and can be reached by other people or systems.

The normal path from local to live

Most projects follow this sequence:

Build in local project folderTest locallySave and review with GitPush approved version to GitHubDeploy to cloudLive product for usersMonitor, improve, repeat

You build locally because it is fast and safe. You deploy when the product is ready for others to use. Git sits between those stages as the record of what changed; GitHub is often the bridge that sends the reviewed version to the deployment service.

Many modern services watch a GitHub repository. When you push an approved commit to a branch, the service can build a preview. When you merge that work into main, it can deploy the approved version to the public site. The exact setup varies, but the mental model is stable: local work becomes a reviewed Git change, GitHub carries it outward, and deployment makes it live.

An AI agent can help with every step, but the authority changes. It is reasonable to let an agent create a local test page. Publishing a new database, connecting a payment system, or exposing data to the public requires a clearer review moment from you.

Credentials change the stakes

Local and cloud systems often connect through credentials: API keys, database passwords, access tokens, and service accounts. These prove that your project is allowed to use another service.

Keep them in environment variables, often stored locally in a file named .env:

DATABASE_URL=...
OPENAI_API_KEY=...

Never paste real secrets into an article, commit them to Git, or casually show them to an agent. A .env.example file is different: it can show the variable names without the real values.

DATABASE_URL=
OPENAI_API_KEY=

That lets another person or agent understand what must be configured without receiving the keys themselves.

The most common confusion: a live-looking local app

You may build something at localhost and see it perfectly in your browser. That does not mean it is deployed. It is a private preview running on your machine.

You may also change a local file and expect the public website to update. It will not. The cloud version is a separate running copy. It needs a deployment process to receive your new code.

Think of local and cloud as a workshop and a storefront:

• The workshop is where you make and test the product.
• The storefront is where customers see the approved version.

The product may be the same, but the environments have different jobs.

What to tell an AI agent

Be explicit about the environment and authority you intend to give it.

Good request:

When you are ready to deploy:

This is not fear. It is good systems practice. The agent can do the work; you retain the decision about what becomes public, paid, or permanent.

Practical exercise: identify the environments you already use

Choose one project and answer these questions:

1. Where is the project folder on your computer? 2. Can you run it locally? What is the localhost address? 3. Where is the public version hosted, if one exists? 4. Which GitHub repository and branch represent the current live version? 5. Which services does it connect to: database, AI model, email, payments, storage? 6. Which credentials would be dangerous to expose?

Put the answers in README.md or CONTEXT.md. The next AI session should not have to guess whether it is working on a local experiment or a live business.

Check your understanding

1. What does localhost mean? 2. Why can an app work locally but not be public? 3. What is the difference between a .env file and .env.example? 4. Why should an AI explain a cloud deployment before it performs one? 5. How do Git and GitHub usually fit between local work and a live deployment?