ENVIRONMENT / HELP ME CHOOSE

Compare environments before you choose.

This guide is optional. Use it only if a must-have leaves you unsure. It compares your options. It does not install anything, and it does not choose for you.

SOURCES REVIEWED AUGUST 29, 2026 · RECHECK BEFORE USE

What counts as enough computer.

Every check below asks whether you have enough memory and disk. Here are the numbers to compare against, so the answer is a fact and not a feeling.

	ENOUGH	COMFORTABLE
Memory	8 GB	16 GB
Free disk	40 GB	60 GB
Processor	2 cores	4 cores

WEEKS 0–4

Java and a text editor. Almost any working computer from the last ten years can do this part.

WEEKS 5–12

A database, an API and a web front end all run at once. This is where 4 GB starts to hurt and 8 GB is fine.

WEEK 14

The heaviest week. Kubernetes on your own machine asks for 2 free cores, 2 GB of free memory and 20 GB of free disk.

An 8 GB computer carries the whole course. Close the extra browser tabs in Week 14 and you will be fine. Below 8 GB, plan to use a cloud VM or Codespaces from Week 9, and write that in your fallback.

Free disk is the one people get wrong. Java, the Maven cache, Node packages and container images all grow quietly over the weeks.

Where the Week 14 numbers come from ↗

If you have no strong reason, start here.

Comparing five options is useful when something rules one out. When nothing does, pick the usual answer for your computer and move on. You can change later, and Week 0 asks you to write down what would make you.

YOU ARE ON WINDOWS
Windows with WSL 2
You keep every Windows app. Your shell and files behave like the Linux the rest of the industry runs. Docker uses WSL 2 anyway from Week 14.
YOU ARE ON A MAC
macOS, locally
The terminal is already close to Linux. Nothing to add underneath.
YOU ARE ON LINUX
Linux, locally
You are already there. Check your version still gets updates.
YOUR COMPUTER IS TOO SMALL, OR NOT YOURS TO CHANGE
A cloud VM, or Codespaces
Rented hardware, and someone else's rules do not block you. It costs money, so read the cost steps first.

ONE THING NOT TO DO

Don't wipe Windows or set up dual boot for this course. It risks the computer you depend on and buys you nothing here. WSL 2 gives you the same Linux without touching your disk layout.

On a computer with 8 GB, cap how much memory WSL may take, so Windows keeps enough for itself. Microsoft's WSL settings page shows the one file that does it.

How to cap what WSL uses ↗

Compare only the options that pass your must-haves.

Windows native

Good fit when: Your commands will run right on a supported Windows computer. Windows-only software or a work policy makes adding a Linux layer a bad idea.

Tradeoff: You must use Windows paths and PowerShell scripts everywhere, every time. Later, Linux containers need virtualization: a Windows feature that runs a small Linux machine inside Windows. It must be supported and turned on.

Check: Check the exact Windows version and the chip type (x86_64 or ARM). Check that you can install software, that you have free memory and disk, and that virtualization is on.

Python on Windows ↗Docker Desktop on Windows ↗

Windows with WSL 2

Good fit when: You want to keep your Windows desktop apps. Your tools, projects, and commands will all run inside WSL 2, a real Linux that lives inside Windows.

Tradeoff: Your project files must stay on the Linux side. Never point Windows tools and WSL tools at the same folder. That causes path errors, slow files, and confusion about which side owns what.

Check: Check that your Windows supports WSL 2, that virtualization is allowed, and that you have free memory and disk. Check that your editor can open a project stored on the Linux side.

Compare WSL versions ↗WSL file-system guidance ↗

macOS

Good fit when: Your commands will run on a supported Mac. Its terminal, its desktop apps, and its chip type all meet your must-haves.

Tradeoff: You must know whether your Mac has an Intel chip or Apple silicon. Then check that every package, and later every container image, matches that chip type.

Check: Check the exact macOS version, the chip type, whether you can install software, and free memory and disk. Then check that Java, Python, and Docker currently support that Mac.

Python on macOS ↗Docker multi-platform builds ↗

Linux installed locally

Good fit when: Your commands will run on a Linux computer you keep up to date, such as Ubuntu or Fedora. Its kind of Linux, its hardware support, and the apps you need all meet your must-haves.

Tradeoff: Every choice about packages, permissions, services, and hardware is yours, and it changes with your kind of Linux. A Linux built on top of another Linux is not automatically tested by the tool makers. For example, Linux Mint is built on Ubuntu.

Check: Check exactly which Linux and which version, plus the chip type. Check whether you have sudo (admin rights) and enough free memory and disk. Then check that the makers of every required tool support that exact combination.

Docker Engine platforms ↗minikube requirements ↗

Remote or browser-based Linux

Good fit when: You would rather not install on your own computer. A Linux VM (a rented computer in the cloud) or a Linux workspace in your browser fits better. Common reasons: weak hardware, a work policy, moving between computers, or limited access to your own machine.

Tradeoff: You now depend on things you don't fully control. Internet, your account, cost or usage limits, and a working SSH or browser connection all become must-haves. Your files must still be there after you close and reopen. Later, containers and Kubernetes must work there too.

Check: Check the cloud provider's current billing controls and which Linux images it supports. Check its memory, CPU, and disk limits. Check how you connect, what stop and delete do, and how long your files are kept. Check what later container work will need.

GitHub Codespaces overview ↗Ubuntu certified public clouds ↗

Decide in eight steps.

01
Write down your must-haves.
WHAT THIS STEP TEACHES
“I can tell a must-have, which rules an option out, from a nice-to-have, which only affects comfort.”
IDEA IN PLAIN ENGLISH
A must-have (a hard constraint) makes an option impossible. A nice-to-have (a preference) only helps you compare the options that are still possible.
WHY THE JOB CARES
Real engineering starts with the requirements. That stops habit or fashion from quietly becoming a technical rule.
BEFORE YOU ACT
Predict which one must-have is most likely to rule out an option.
EXPLAIN IT BACK
Explain why each must-have cannot bend, and what proof would change your mind.
COMMON TRAP
Don't copy another learner's choice. First check your own work policy, cost, hardware, accessibility needs, and internet.
GUIDED ACTION
Make a list. Include: whether you can install software, the apps you need, accessibility needs, and whether you must work offline. Add how reliable your internet is, your budget, and your hardware limits. Mark each line must-have or nice-to-have.
CHECK BEFORE CONTINUING
Every must-have has a real reason and a way to test it that you can see.
02
List the facts about the computer you already have.
WHAT THIS STEP TEACHES
“I can describe my computer using the same exact facts that the tool makers' support pages use.”
IDEA IN PLAIN ENGLISH
Whether a tool works depends on the exact version, chip type, memory, disk, features, and admin rights. The brand name alone is not enough.
WHY THE JOB CARES
If even one part of that exact combination is unsupported, an installer or a container can fail.
BEFORE YOU ACT
Predict each value before you read it off the computer.
EXPLAIN IT BACK
Name the fact that decides which package to install. Name the one that limits how much you can run. Name the one that controls what you are allowed to do.
COMMON TRAP
Don't guess the chip type from how old the computer is. Don't guess free disk from the size printed on the box.
GUIDED ACTION
Read these off the computer: the operating system version, the chip type, and total and free memory. Then the free disk where you will work, whether virtualization is on, and your admin or sudo rights.
CHECK BEFORE CONTINUING
Every required field has a real value you saw, plus a way to check it again later.
03
Cross out the options that can't work.
WHAT THIS STEP TEACHES
“I can run every option through the same must-have filter.”
IDEA IN PLAIN ENGLISH
First remove the impossible options. Only then compare the rest by what you'd prefer.
WHY THE JOB CARES
Teams waste hours arguing about options that already break a policy, cost, access, or hardware rule.
BEFORE YOU ACT
Predict which options will survive the filter.
EXPLAIN IT BACK
Pick one option you crossed out. Name the must-have it failed, without calling the option bad in general.
COMMON TRAP
Don't soften a must-have just to keep an option you like.
GUIDED ACTION
Cross out each option that fails even one must-have. Next to it, write exactly which must-have it failed.
CHECK BEFORE CONTINUING
Every crossed-out option names one failed must-have. Every option still standing passes all of them.
04
Check that the tool makers support your setup today.
WHAT THIS STEP TEACHES
“I can say, from the official docs, that a specific version is supported on my exact setup.”
IDEA IN PLAIN ENGLISH
A full support claim names the product, the version, and your exact combination (operating system plus chip type). It also names the official source, the date you checked, and any limits.
WHY THE JOB CARES
A guide you remember can be out of date, even when its commands still seem to work.
BEFORE YOU ACT
Before you open each product's page, predict: supported or not?
EXPLAIN IT BACK
Say one full support claim out loud. Point to the exact sentence or table in the docs that backs it up.
COMMON TRAP
Don't assume a related version or kind of Linux is tested unless the docs say so clearly.
GUIDED ACTION
For each option still standing, open the official Java, Python, Docker, and minikube docs. Check your exact version and chip type in each.
CHECK BEFORE CONTINUING
Every required tool has a dated official source, or a clear note that it is not supported.
05
Name the one place where your commands run.
WHAT THIS STEP TEACHES
“I can say where my commands run, where my files live, and which installed tools own the project.”
IDEA IN PLAIN ENGLISH
One project belongs to one shell, one file system, one set of installed packages, and one set of permissions. Keep them all on the same side.
WHY THE JOB CARES
Crossing sides by accident means two copies of each tool, rewritten paths, slow files, and confusion about ownership.
BEFORE YOU ACT
Predict what the right prompt looks like, where the project path is, and where the tools live.
EXPLAIN IT BACK
Describe how you would notice that you opened the wrong terminal, or the wrong cloud website.
COMMON TRAP
Don't install the same tool on both sides to paper over a problem you haven't found yet.
GUIDED ACTION
Write one sentence. Name the computer where your commands run and the file system where the project lives. Name the shell you will use for every week page.
CHECK BEFORE CONTINUING
One sentence names the computer, the shell, where the project is stored, and which side owns the tools.
06
Pick a fallback (your backup plan) and what would trigger it.
WHAT THIS STEP TEACHES
“I can make my choice easy to undo without keeping two full setups running.”
IDEA IN PLAIN ENGLISH
A fallback is your backup plan. You switch to it only after one clear failure you can see.
WHY THE JOB CARES
When policy, hardware, cost, or internet changes, a named backup plan gets you back to work faster.
BEFORE YOU ACT
Predict the most likely serious failure of your first choice.
EXPLAIN IT BACK
Explain why the fallback would not fail in the same way as your first choice.
COMMON TRAP
Don't install and keep up the fallback now. Two live setups means you never know which one is the real one.
GUIDED ACTION
Pick a second option that is still possible. Then write the exact event that would make you switch. Examples: an unsupported version, a denied admin right, a memory or disk limit, a cost, or a lost connection.
CHECK BEFORE CONTINUING
The fallback passes every must-have and has one clear trigger you can see.
07
Choose your setup.
WHAT THIS STEP TEACHES
“I can choose one setup based on facts, without claiming it is the best for everyone.”
IDEA IN PLAIN ENGLISH
A decision is a tradeoff for your situation. It is not a ranking, and it is not who you are.
WHY THE JOB CARES
Once you choose, every later instruction can use one shell, one path style, and one side.
BEFORE YOU ACT
Say your likely choice and its main cost in one sentence.
EXPLAIN IT BACK
Defend your choice with one must-have, one support fact from the docs, one tradeoff, and your fallback trigger.
COMMON TRAP
Once you have picked an option that works, stop reading about all the others.
GUIDED ACTION
Go back to the environment chooser. Pick where your commands will run, then answer the follow-up questions about which kind and which provider.
CHECK BEFORE CONTINUING
The site shows your one saved choice and sends you to only that setup guide.
08
Prove your choice works, or change it.
WHAT THIS STEP TEACHES
“I can test my setup choice by what the tools and the project actually do.”
IDEA IN PLAIN ENGLISH
Your choice is only a guess until a brand-new shell window can run every required step.
WHY THE JOB CARES
An installer's Done screen proves very little. It does not prove the shell still finds the tool after a restart. It does not prove the compiler runs, the project stays separate, or the tests run.
BEFORE YOU ACT
Predict the result of every check, and whether the check will change any files.
EXPLAIN IT BACK
Say what each result proves, what it does not prove, and whether the fallback trigger happened.
COMMON TRAP
One version command is not the whole proof. Neither is a terminal inside an editor that was already set up.
GUIDED ACTION
Follow only the setup guide you chose. Close and reopen the shell, then run every required check. Save your proof with private details removed. Switch to the fallback only if its named trigger actually happens.
CHECK BEFORE CONTINUING
A brand-new shell prints the required versions and passes the project checks, and you can explain each result.

Return to the environment chooser →

What counts as enough computer.

Every check below asks whether you have enough memory and disk. Here are the numbers to compare against, so the answer is a fact and not a feeling.

	ENOUGH	COMFORTABLE
Memory	8 GB	16 GB
Free disk	40 GB	60 GB
Processor	2 cores	4 cores

WEEKS 0–4

Java and a text editor. Almost any working computer from the last ten years can do this part.

WEEKS 5–12

A database, an API and a web front end all run at once. This is where 4 GB starts to hurt and 8 GB is fine.

WEEK 14

The heaviest week. Kubernetes on your own machine asks for 2 free cores, 2 GB of free memory and 20 GB of free disk.

An 8 GB computer carries the whole course. Close the extra browser tabs in Week 14 and you will be fine. Below 8 GB, plan to use a cloud VM or Codespaces from Week 9, and write that in your fallback.

Free disk is the one people get wrong. Java, the Maven cache, Node packages and container images all grow quietly over the weeks.

If you have no strong reason, start here.

YOU ARE ON WINDOWS

Windows with WSL 2

You keep every Windows app. Your shell and files behave like the Linux the rest of the industry runs. Docker uses WSL 2 anyway from Week 14.

YOU ARE ON A MAC

macOS, locally

The terminal is already close to Linux. Nothing to add underneath.

YOU ARE ON LINUX

Linux, locally

You are already there. Check your version still gets updates.

YOUR COMPUTER IS TOO SMALL, OR NOT YOURS TO CHANGE

A cloud VM, or Codespaces

Rented hardware, and someone else's rules do not block you. It costs money, so read the cost steps first.

ONE THING NOT TO DO

Don't wipe Windows or set up dual boot for this course. It risks the computer you depend on and buys you nothing here. WSL 2 gives you the same Linux without touching your disk layout.

On a computer with 8 GB, cap how much memory WSL may take, so Windows keeps enough for itself. Microsoft's WSL settings page shows the one file that does it.

Compare only the options that pass your must-haves.

Windows native

Good fit when: Your commands will run right on a supported Windows computer. Windows-only software or a work policy makes adding a Linux layer a bad idea.

Check: Check the exact Windows version and the chip type (x86_64 or ARM). Check that you can install software, that you have free memory and disk, and that virtualization is on.

Python on Windows ↗Docker Desktop on Windows ↗

Windows with WSL 2

Good fit when: You want to keep your Windows desktop apps. Your tools, projects, and commands will all run inside WSL 2, a real Linux that lives inside Windows.

Tradeoff: Your project files must stay on the Linux side. Never point Windows tools and WSL tools at the same folder. That causes path errors, slow files, and confusion about which side owns what.

Check: Check that your Windows supports WSL 2, that virtualization is allowed, and that you have free memory and disk. Check that your editor can open a project stored on the Linux side.

Compare WSL versions ↗WSL file-system guidance ↗

macOS

Good fit when: Your commands will run on a supported Mac. Its terminal, its desktop apps, and its chip type all meet your must-haves.

Tradeoff: You must know whether your Mac has an Intel chip or Apple silicon. Then check that every package, and later every container image, matches that chip type.

Check: Check the exact macOS version, the chip type, whether you can install software, and free memory and disk. Then check that Java, Python, and Docker currently support that Mac.

Python on macOS ↗Docker multi-platform builds ↗

Linux installed locally

Good fit when: Your commands will run on a Linux computer you keep up to date, such as Ubuntu or Fedora. Its kind of Linux, its hardware support, and the apps you need all meet your must-haves.

Docker Engine platforms ↗minikube requirements ↗

Remote or browser-based Linux

GitHub Codespaces overview ↗Ubuntu certified public clouds ↗

Decide in eight steps.

Write down your must-haves.

WHAT THIS STEP TEACHES

“I can tell a must-have, which rules an option out, from a nice-to-have, which only affects comfort.”

IDEA IN PLAIN ENGLISH

A must-have (a hard constraint) makes an option impossible. A nice-to-have (a preference) only helps you compare the options that are still possible.

WHY THE JOB CARES

Real engineering starts with the requirements. That stops habit or fashion from quietly becoming a technical rule.

BEFORE YOU ACT

Predict which one must-have is most likely to rule out an option.

EXPLAIN IT BACK

Explain why each must-have cannot bend, and what proof would change your mind.

COMMON TRAP

Don't copy another learner's choice. First check your own work policy, cost, hardware, accessibility needs, and internet.

GUIDED ACTION

Make a list. Include: whether you can install software, the apps you need, accessibility needs, and whether you must work offline. Add how reliable your internet is, your budget, and your hardware limits. Mark each line must-have or nice-to-have.

CHECK BEFORE CONTINUING

Every must-have has a real reason and a way to test it that you can see.

List the facts about the computer you already have.

WHAT THIS STEP TEACHES

“I can describe my computer using the same exact facts that the tool makers' support pages use.”

IDEA IN PLAIN ENGLISH

Whether a tool works depends on the exact version, chip type, memory, disk, features, and admin rights. The brand name alone is not enough.

WHY THE JOB CARES

If even one part of that exact combination is unsupported, an installer or a container can fail.

BEFORE YOU ACT

Predict each value before you read it off the computer.

EXPLAIN IT BACK

Name the fact that decides which package to install. Name the one that limits how much you can run. Name the one that controls what you are allowed to do.

COMMON TRAP

Don't guess the chip type from how old the computer is. Don't guess free disk from the size printed on the box.

GUIDED ACTION

Read these off the computer: the operating system version, the chip type, and total and free memory. Then the free disk where you will work, whether virtualization is on, and your admin or sudo rights.

CHECK BEFORE CONTINUING

Every required field has a real value you saw, plus a way to check it again later.

Cross out the options that can't work.

WHAT THIS STEP TEACHES

“I can run every option through the same must-have filter.”

IDEA IN PLAIN ENGLISH

First remove the impossible options. Only then compare the rest by what you'd prefer.

WHY THE JOB CARES

Teams waste hours arguing about options that already break a policy, cost, access, or hardware rule.

BEFORE YOU ACT

Predict which options will survive the filter.

EXPLAIN IT BACK

Pick one option you crossed out. Name the must-have it failed, without calling the option bad in general.

COMMON TRAP

Don't soften a must-have just to keep an option you like.

GUIDED ACTION

Cross out each option that fails even one must-have. Next to it, write exactly which must-have it failed.

CHECK BEFORE CONTINUING

Every crossed-out option names one failed must-have. Every option still standing passes all of them.

Check that the tool makers support your setup today.

WHAT THIS STEP TEACHES

“I can say, from the official docs, that a specific version is supported on my exact setup.”

IDEA IN PLAIN ENGLISH

A full support claim names the product, the version, and your exact combination (operating system plus chip type). It also names the official source, the date you checked, and any limits.

WHY THE JOB CARES

A guide you remember can be out of date, even when its commands still seem to work.

BEFORE YOU ACT

Before you open each product's page, predict: supported or not?

EXPLAIN IT BACK

Say one full support claim out loud. Point to the exact sentence or table in the docs that backs it up.

COMMON TRAP

Don't assume a related version or kind of Linux is tested unless the docs say so clearly.

GUIDED ACTION

For each option still standing, open the official Java, Python, Docker, and minikube docs. Check your exact version and chip type in each.

CHECK BEFORE CONTINUING

Every required tool has a dated official source, or a clear note that it is not supported.

Name the one place where your commands run.

WHAT THIS STEP TEACHES

“I can say where my commands run, where my files live, and which installed tools own the project.”

IDEA IN PLAIN ENGLISH

One project belongs to one shell, one file system, one set of installed packages, and one set of permissions. Keep them all on the same side.

WHY THE JOB CARES

Crossing sides by accident means two copies of each tool, rewritten paths, slow files, and confusion about ownership.

BEFORE YOU ACT

Predict what the right prompt looks like, where the project path is, and where the tools live.

EXPLAIN IT BACK

Describe how you would notice that you opened the wrong terminal, or the wrong cloud website.

COMMON TRAP

Don't install the same tool on both sides to paper over a problem you haven't found yet.

GUIDED ACTION

Write one sentence. Name the computer where your commands run and the file system where the project lives. Name the shell you will use for every week page.

CHECK BEFORE CONTINUING

One sentence names the computer, the shell, where the project is stored, and which side owns the tools.

Pick a fallback (your backup plan) and what would trigger it.

WHAT THIS STEP TEACHES

“I can make my choice easy to undo without keeping two full setups running.”

IDEA IN PLAIN ENGLISH

A fallback is your backup plan. You switch to it only after one clear failure you can see.

WHY THE JOB CARES

When policy, hardware, cost, or internet changes, a named backup plan gets you back to work faster.

BEFORE YOU ACT

Predict the most likely serious failure of your first choice.

EXPLAIN IT BACK

Explain why the fallback would not fail in the same way as your first choice.

COMMON TRAP

Don't install and keep up the fallback now. Two live setups means you never know which one is the real one.

GUIDED ACTION

Pick a second option that is still possible. Then write the exact event that would make you switch. Examples: an unsupported version, a denied admin right, a memory or disk limit, a cost, or a lost connection.

CHECK BEFORE CONTINUING

The fallback passes every must-have and has one clear trigger you can see.

Choose your setup.

WHAT THIS STEP TEACHES

“I can choose one setup based on facts, without claiming it is the best for everyone.”

IDEA IN PLAIN ENGLISH

A decision is a tradeoff for your situation. It is not a ranking, and it is not who you are.

WHY THE JOB CARES

Once you choose, every later instruction can use one shell, one path style, and one side.

BEFORE YOU ACT

Say your likely choice and its main cost in one sentence.

EXPLAIN IT BACK

Defend your choice with one must-have, one support fact from the docs, one tradeoff, and your fallback trigger.

COMMON TRAP

Once you have picked an option that works, stop reading about all the others.

GUIDED ACTION

Go back to the environment chooser. Pick where your commands will run, then answer the follow-up questions about which kind and which provider.

CHECK BEFORE CONTINUING

The site shows your one saved choice and sends you to only that setup guide.

Prove your choice works, or change it.

WHAT THIS STEP TEACHES

“I can test my setup choice by what the tools and the project actually do.”

IDEA IN PLAIN ENGLISH

Your choice is only a guess until a brand-new shell window can run every required step.

WHY THE JOB CARES

An installer's Done screen proves very little. It does not prove the shell still finds the tool after a restart. It does not prove the compiler runs, the project stays separate, or the tests run.

BEFORE YOU ACT

Predict the result of every check, and whether the check will change any files.

EXPLAIN IT BACK

Say what each result proves, what it does not prove, and whether the fallback trigger happened.

COMMON TRAP

One version command is not the whole proof. Neither is a terminal inside an editor that was already set up.

GUIDED ACTION

Follow only the setup guide you chose. Close and reopen the shell, then run every required check. Save your proof with private details removed. Switch to the fallback only if its named trigger actually happens.

CHECK BEFORE CONTINUING

A brand-new shell prints the required versions and passes the project checks, and you can explain each result.