DEV Community: Labby

Docker EXPOSE vs. Publish: Why Your Running Container Is Unreachable

Labby — Mon, 07 Sep 2026 05:51:32 +0000

Your Dockerfile contains EXPOSE 8000. The container is running. docker ps even lists 8000/tcp. Yet opening http://localhost:8080 gives you a connection error.

EXPOSE records a container port in the image's metadata. docker run -p publishes a container port through an address and port on the Docker host. Neither instruction makes your application start listening. These are three separate controls, and a working browser request depends on more than the first one.

This guide uses one small HTTP server to reproduce three states: an unpublished port, a working published port, and a published port pointing at an unreachable listener. You will inspect each state before changing it, so the commands remain useful when your next container has a different application inside.

What EXPOSE, publish, and bind actually control

Setting	Where it belongs	What it does	What it does not prove
`EXPOSE 8000`	Dockerfile	Records an intended container port	That a server is running or a host port exists
`-p 127.0.0.1:8080:8000`	`docker run`	Maps host loopback port 8080 to container port 8000	That the application accepts that traffic
`--bind 0.0.0.0`	Our Python server command	Makes the application listen on all IPv4 interfaces inside its container	That Docker publishes a host port

Docker's Dockerfile reference explicitly separates exposing from publishing. An image can document a port without making it available through localhost on the host. Conversely, an explicit -p mapping can target a port that the Dockerfile never declared.

For this example, read the publishing argument from left to right:

-p 127.0.0.1:8080:8000
   └ host IP  │    └ container port
              └ host port

Host request to 127.0.0.1:8080
    → Docker port mapping
    → container network interface, port 8000
    → HTTP server

The two port numbers need not match. Use 8080 in the host-side URL because that is the entrance you created; the server still listens on 8000 inside the container. Docker documents this syntax in its port publishing walkthrough.

Prepare one server you can test from both sides

You need a working Docker Engine, a terminal with a POSIX shell, curl, and permission to run Docker commands. Check the engine before copying the example:

docker version

You should see both Client and Server information. A missing Server section or a daemon connection error is an environment problem to resolve first. This guide uses Linux containers on Docker's ordinary bridge network; it does not use --network host or custom routing rules.

The experiments and screenshots below were captured in a LabEx Ubuntu 22.04 instance VM with Docker Engine 20.10.21 on September 7, 2026. The image tag python:3.12-alpine can change over time. The experiment concerns port behavior, rather than a specific Python patch release.

If creating images and running named containers are new to you, the Docker for Beginners course includes Docker Run Command Parameters, Custom Docker Images, and Docker Networking Basics. Those activities provide the surrounding practice for this example.

Create an empty working directory:

mkdir docker-port-demo
cd docker-port-demo

Save this as index.html. The page deliberately has no application dependencies: if it loads, an HTTP request reached the server.

<!doctype html>
<html lang="en">
  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width" />
  <title>Docker port demo</title>
  <style>
    body {
      font: 22px/1.6 system-ui;
      max-width: 760px;
      margin: 12vh auto;
      padding: 32px;
      color: #18334a;
      background: #f1f7fa;
    }
    h1 {
      font-size: 44px;
      line-height: 1.15;
    }
    code {
      background: #dcecf5;
      padding: 3px 9px;
      border-radius: 6px;
    }
  </style>
  <p>DOCKER NETWORKING EXPERIMENT</p>
  <h1>Your request reached the container.</h1>
  <p>This page is served by Python on container port <code>8000</code>.</p>
  <p>
    Change the port mapping or listening address, then test the same request
    again.
  </p>
</html>

In the same directory, save this as Dockerfile:

FROM python:3.12-alpine
WORKDIR /site
COPY index.html .
EXPOSE 8000
CMD ["python", "-u", "-m", "http.server", "8000", "--bind", "0.0.0.0"]

WORKDIR selects the directory to serve, COPY adds the page, and CMD starts the process. The -u option makes Python's output unbuffered, which helps when reading startup messages through container logs. The EXPOSE line describes the port; the http.server command is what opens the listener.

Build the image:

docker build -t port-demo .

Python's HTTP server documentation explains the command-line bind option and cautions against using this server for production. Use this small static page for the experiment, not as a deployment template for a sensitive application.

Experiment 1: EXPOSE without a published port

Start the image without -p:

docker run -d --name exposed-only port-demo

Inspect the image metadata and the running container:

docker image inspect port-demo --format '{{json .Config.ExposedPorts}}'
docker ps --filter name=exposed-only --format 'table {{.Names}}\t{{.Ports}}'
docker port exposed-only

The image records {"8000/tcp":{}}, and the container's port column shows 8000/tcp. However, docker port exposed-only produces no mapping. The docker port reference defines this command as a mapping inspection tool; it is not an application health check.

Try a request from the Docker host terminal:

curl --max-time 3 http://127.0.0.1:8080/

It should fail if nothing else is listening on host port 8080. If it succeeds, inspect that other service before continuing: this container did not publish that address.

Now make a request inside the container:

docker exec exposed-only python -c 'import urllib.request; print(urllib.request.urlopen("http://127.0.0.1:8000").status)'

The result is 200. This test uses Python because the image already contains it; you do not need to install curl inside the container.

Together, the observations say something precise: the application answers HTTP internally, but this container has no host port mapping. They do not say that the application is inaccessible from every possible network location. On a Linux bridge, the host and other containers on the same bridge may reach a reachable container listener directly. Docker explains that distinction in its bridge network documentation.

Experiment 2: publish the host entrance

Start a second container from exactly the same image:

docker run -d --name published -p 127.0.0.1:8080:8000 port-demo

After the server starts, inspect and test it:

docker port published
curl -s -o /dev/null -w 'Host HTTP status: %{http_code}\n' http://127.0.0.1:8080/

The mapping is 8000/tcp -> 127.0.0.1:8080, and the request returns Host HTTP status: 200. If a request made immediately after docker run fails, check the logs and retry after startup; creating the container and accepting HTTP are separate events.

The same image, tested in a LabEx VM. Adding a host mapping changes the host request result without changing the Dockerfile.

You can now open http://127.0.0.1:8080 in a browser on the Docker host. If Docker runs in a remote VM, your laptop's browser is a different machine; use the remote-preview section below.

Why specify 127.0.0.1? With Docker's default settings, omitting the host IP publishes on all host interfaces. Explicit loopback binding is the appropriate starting point for a local development example. It does not add authentication or encryption. Docker also documents a caveat for engines older than 28.0.0: another host on the same layer-2 network may reach a localhost-published port. Our older demonstration VM is not evidence that loopback publishing provides complete isolation. See Docker's publishing and mapping security notes.

Experiment 3: a mapping exists, but the listener is wrong

Now keep port publishing and change only the application's listening address. Use host port 8081 so the working container can remain available for comparison:

docker run -d --name wrong-bind -p 127.0.0.1:8081:8000 \
  port-demo python -u -m http.server 8000 --bind 127.0.0.1

The command after port-demo replaces this image's default CMD. Python now listens only on the container's loopback interface.

Check the mapping, then test from the host:

docker port wrong-bind
curl --max-time 3 http://127.0.0.1:8081/

A mapping exists, yet the HTTP request fails. Depending on your engine and network implementation, the error may be a reset or another connection failure; the important observation is that you do not receive the page.

Repeat the internal check:

docker exec wrong-bind python -c 'import urllib.request; print(urllib.request.urlopen("http://127.0.0.1:8000").status)'
docker logs --tail 5 wrong-bind

The internal request returns 200, and the startup log identifies 127.0.0.1 as the bind address.

Port forwarding exists. The application is listening at the wrong address for traffic arriving through the container's network interface.

There are two different loopbacks here. 127.0.0.1 in the publishing argument belongs to the host. 127.0.0.1 in the Python command belongs to the container. Forwarded traffic arrives at the container's network interface, not its private loopback listener.

For this server, restore --bind 0.0.0.0 by recreating the container with the image's default command:

docker rm -f wrong-bind
docker run -d --name wrong-bind -p 127.0.0.1:8081:8000 port-demo
curl --retry 5 --retry-all-errors --retry-delay 1 http://127.0.0.1:8081/

This final read-only request retries startup connection failures, including resets. The --retry-all-errors option requires curl 7.71.0 or newer; with an older curl, wait for the startup log and repeat the request manually.

The host-side mapping can stay on 127.0.0.1 while the application listens on 0.0.0.0 inside the container. These settings control different boundaries. 0.0.0.0 is a listening address meaning all IPv4 interfaces in that network namespace, not the URL to type into your browser.

Viewing the page from a LabEx VM

A remote experiment adds another step to the request path:

Your browser → LabEx web preview → VM port 8082
             → Docker mapping → container port 8000

For the captured browser demonstration, we started a separate preview container:

docker run -d --name preview -p 8082:8000 port-demo

This mapping omits a host IP so the VM's preview service can reach it. In the LabEx environment, open a web preview for VM port 8082 and use the provided preview URL. The exact preview controls depend on the lab environment. Typing localhost:8082 into your laptop browser would target your laptop instead.

The actual example page reached through the LabEx VM preview. The temporary environment URL is excluded from the capture.

Only the disposable static demo is being served here. On your own remote server, publishing on all interfaces changes who may reach the application; choose the host binding and any surrounding network controls deliberately. A successful curl inside the VM followed by a failed external preview means you should inspect the preview port and intervening network path before editing EXPOSE again.

A troubleshooting order that preserves the evidence

When another container is unreachable, start with the closest observable boundary and work outward.

Question	Check	How to interpret it
Is the container still running?	`docker ps -a --filter name=published`	An exited process needs log inspection before networking changes
What did the application report?	`docker logs --tail 50 published`	Look for startup errors, port numbers, and bind addresses
What command actually started?	`docker inspect published --format '{{json .Config.Cmd}}'`	A runtime override may differ from the Dockerfile
Is there a host mapping?	`docker port published`	No mapping means no published host entrance for this container
Does HTTP work inside?	Use the internal Python request above	Success establishes internal HTTP response, not outside reachability
Does HTTP work on the Docker host?	`curl -v --max-time 3 http://127.0.0.1:8080/`	Failure with internal success narrows attention to mapping and bind address
Does the remote browser use the same host and port?	Compare its destination with the VM preview configuration	A laptop localhost URL does not target a remote VM

The logs command retrieves container output, while inspect returns configuration and state. Neither replaces a request to the actual endpoint. Some applications also write logs to files rather than standard output, so an empty docker logs result is not proof that nothing happened.

If Docker reports that a host port is already allocated, change the host number, for example to 127.0.0.1:8083:8000, and use 8083 in your URL. Changing the container number to 8083 would point forwarding at a port where this server is not listening.

An HTTP 404 or 500 is different from a connection failure: an HTTP server responded. Confirm you reached the intended service, then investigate its path or application behavior. Repeatedly rebuilding the image to add more EXPOSE lines will not explain an HTTP error response.

Questions that come up next

Do I need EXPOSE if I already use -p?

No. Explicit publishing does not require an EXPOSE declaration. Keeping the declaration can still communicate the image's intended port to people and tools. It should agree with the application configuration, but it does not enforce that configuration.

To test that distinction yourself, remove EXPOSE 8000, build under a second tag, and run it with an explicit mapping on an unused host port. Avoid using a base image that already declares the same port if your experiment is intended to show the absence of exposed-port metadata.

What is the difference between -p and -P?

Lowercase -p specifies a publication, such as -p 127.0.0.1:8080:8000. Uppercase -P publishes all exposed ports to automatically selected host ports. Inspect the resulting mappings rather than guessing the chosen numbers. Neither option changes the application's listening port or address.

Does Compose expose publish a port?

No. For the working example, the equivalent host publication belongs under ports:

services:
  web:
    image: port-demo
    ports:
      - "127.0.0.1:8080:8000"

Stop the earlier published container before starting this service, because both would otherwise claim host port 8080. The image must already exist on the Docker host for this example.

Compose's expose describes container ports without publishing them to the host. It is not a firewall between services. The official Compose services reference documents both fields and their different purposes.

Do two containers need published ports to communicate?

Not when they can already communicate over the same user-defined bridge network. They can use a container name and the application's container port, such as web:8000; the application still needs to listen on a reachable interface. Publishing is for the additional host entrance. Do not publish a database port merely because another container needs to talk to the database.

Clean up, then practice a different failure

Remove only the containers created by this guide:

docker rm -f exposed-only published wrong-bind preview

If you skipped the preview step, Docker will report that preview does not exist. If you tried the optional Compose example, stop it with docker compose down from its project directory as well. Keep port-demo if you want to repeat the experiments; otherwise remove that image with docker image rm port-demo.

For the next practice session, choose the gap your experiment exposed:

If reading docker run arguments was the hard part, work through Docker Run Command Parameters.
If you want to extend the example to container networks, continue with Docker Networking Basics and Docker Network Playground.
If addresses, processes, and service troubleshooting still feel disconnected, use the networking and service checkpoints in the Linux learning roadmap.

Repeat the failed request before applying a fix, change one boundary, and repeat the same request afterward. The useful result is being able to explain which observation changed and why.

References

Dockerfile reference: EXPOSE — exposed-port metadata and its relationship to explicit publishing.
Docker: Publishing and exposing ports — mapping syntax and automatically selected host ports.
Docker: Port publishing and mapping — host binding scope and the pre-28.0.0 localhost caveat.
Docker: Bridge network driver — communication within a bridge and name resolution on user-defined networks.
Docker CLI: container port — inspect an existing port mapping.
Docker CLI: container logs and container inspect — distinguish application output from container configuration.
Docker Compose services reference — ports, expose, and service configuration.
curl manual — retry behavior for the post-startup verification request.
Python 3.12: http.server — the demonstration server, bind address, and production limitations.
LabEx: Docker for Beginners — the related image, container, and networking practice sequence.

Linux Learning Roadmap for 2026: From Your First Command to Running a Service

Labby — Mon, 07 Sep 2026 05:51:05 +0000

A service cannot read its configuration file. You can find the file and open it yourself, but restarting the service changes nothing. What would you inspect next: the path, the file's owner, the directory permissions, or the identity running the service?

That question connects several parts of Linux that beginners often study separately. A useful learning roadmap should help you make those connections. Its checkpoints should tell you what you can now investigate and fix, not just which commands you have seen.

The route below starts with a terminal and ends with maintaining a small service: checking its files, reading its logs, tracing a connection, and recovering a configuration. Use the checkpoints to choose your starting point. Looking up syntax is allowed; being able to explain and verify the change is the test.

The roadmap at a glance

Stage	Learn to work with	Move on when you can…
Choose an environment	Distribution, shell, user, system capabilities	Identify where commands run and which administration tasks the environment supports
Navigate and edit	Paths, help, files, directories, a text editor	Find a configuration, edit a copy, and check exactly what changed
Control access	Users, groups, ownership, file and directory permissions	Give the intended identity access and verify the access boundary
Process text	Standard streams, pipes, filters, exit status	Produce a repeatable report from a log file
Inspect a running system	Processes, packages, services, journals	Use evidence to recover a failed service
Trace connections	Addresses, routes, DNS, listening sockets, SSH	Separate a name-resolution problem from a connection or service problem
Automate and recover	Scripts, disk space, archives, scheduling	Run a task reliably and restore a selected file from its backup

This is a learning sequence, not a fixed number of weeks. If you already edit files and understand permissions, try those checkpoints and begin where your explanation breaks down. If a later task exposes a gap, return to the relevant stage.

The scope is consistent with established introductory curricula. LPI Linux Essentials includes files, permissions, archives, recovery, and simple scripts. The Linux Foundation's Introduction to Linux also covers processes, networking, Bash, and local security. Neither source establishes a universal learning order; the order here follows the dependencies of the practice tasks.

Choose an environment you can inspect

Pick one Linux distribution for the main route. Ubuntu is a practical choice for following the package-management documentation linked below. Learn its conventions first, then compare another distribution when you have a reason to do so.

A terminal is the interface you type into. A shell interprets your commands. The distribution supplies the operating-system environment and its package and configuration conventions. Open Bash for the examples in this article and inspect the environment:

cat /etc/os-release
printf '%s\n' "$BASH_VERSION"
id
pwd

Record the distribution, Bash version, current identity, and working directory. These details explain many differences between a tutorial and the system in front of you. A command that exists on one machine may need an additional package on another.

On Windows, WSL is an option, including for some service-management practice. Microsoft documents systemd support in WSL, with requirements and configuration that depend on the installation. Check the actual environment before assuming that a service command will work. For boot, disk, and recovery exercises, choose a disposable Linux VM that exposes the capabilities the exercise requires.

Also distinguish a container from a complete VM. Docker describes containers as isolated processes sharing a kernel. A container shell can be useful for file and scripting work, but its presence does not establish that you can manage a full guest's boot process or services.

If you want a structured starting point, the LabEx Linux path links to Linux courses and practice. Quick Start with Linux is the short entry route; choose a lab environment appropriate to the task as you progress.

Navigate, edit, and check your changes

Start with absolute and relative paths, hidden files, and the relationship between your current directory and a command's arguments. Practise finding help with --help and man. Learn enough of one editor to open, search, change, save, and exit a file.

Build a small practice directory that you will reuse later. Run this once in a new Bash session; keep the terminal open for the subsequent examples. mktemp creates a fresh directory rather than reusing an existing project:

practice_dir=$(mktemp -d)
cd "$practice_dir"
mkdir -p service/{config,logs,backups}
printf 'port=8080\n' > service/config/app.conf
cp service/config/app.conf service/config/app.conf.before
printf '%s\n' "$practice_dir"

The configuration is a practice fixture, not a configuration format for an installed server. Open app.conf in your editor and change the port to 8081. Then inspect the difference:

diff -u service/config/app.conf.before service/config/app.conf

Explain which line changed and which file contains the original. A difference makes diff return status 1; that is its way of reporting unequal inputs, not automatically a command failure.

Your checkpoint is to locate this file from another working directory, edit a copy, and verify the result. If you cannot predict which path a command will touch, spend more time here before practising recursive operations.

The Linux for Noobs course provides the main practice spine for this roadmap. Its public syllabus covers file operations and command help, then continues through permissions, text processing, processes, services, networking, scripting, and recovery. The exercises below are article examples, not reproductions of its lab instructions.

Understand which identity needs access

Read ls -l output in terms of owner, group, and everyone else. Then learn why directories have permission bits too. Directory search permission affects access through a path; reading a file involves more than the bits on that final file.

In the practice directory, inspect both the file and its containing directory:

id
ls -ld service service/config
ls -l service/config/app.conf
chmod 600 service/config/app.conf
ls -l service/config/app.conf

The mode change gives the owner read and write permission and removes the group's and others' mode permissions. This is an appropriate exercise for an owner-only file. It does not prove that the same mode would work for a service running as another user.

That distinction is the checkpoint: state which identity needs access, choose ownership and permissions to match, and test as that identity in an administration lab. Also test the identity that should lack access. Reading the file as your own user proves only your own access. Later, ACLs and mandatory access controls can add further constraints beyond ordinary mode bits.

Linux Journey's file-permissions lesson is a useful companion when you need to decode the permission string. Keep returning to the opening service problem: which user is actually trying to read the configuration?

Turn output into a repeatable report

Before learning long pipelines, understand standard output, standard error, and redirection. Learn a few filters well: grep for selection, cut or awk for fields, and sort with uniq for grouping.

Create a deliberately simple log fixture:

printf '%s\n' \
  'INFO started' \
  'ERROR config-unreadable' \
  'ERROR config-unreadable' \
  'ERROR connection-refused' > service/logs/app.log

awk '$1 == "ERROR" { print $2 }' service/logs/app.log |
  sort |
  uniq -c

For this fixture, the report should count two config-unreadable events and one connection-refused event. It relies on a specific input format: a severity followed by a single-word event. Real logs may use timestamps, quoted fields, JSON, or multiline records; inspect the format before choosing a parser.

Save the report in a file, add another event, and regenerate it. Check that the new count matches the input. Then try a missing input file and observe the error separately from the report.

Exit status becomes important here. In Bash, a pipeline normally reports the last command's status. With pipefail, a failure earlier in the pipeline can affect that result. Consult the Bash pipeline documentation before treating an empty output file as proof of success.

Inspect processes, packages, services, and logs

Now move from prepared files to a running system. Learn to identify a process, its owner, its command, and its resource use. Practise process termination in an exercise with a known target, and distinguish that process from unrelated work.

Use the distribution's package manager to install software and inspect what is installed. Ubuntu's package-management guide explains APT and related tools. Treat that as Ubuntu-specific guidance; RPM-based systems have a different toolchain.

A service manager adds another layer: it manages a program according to a unit's configuration and lifecycle rules. On a systemd-based practice VM, select a service supplied by the exercise and inspect its status, recent journal entries, and unit configuration. Learn the difference between starting it now and enabling it for future activation at boot. The systemctl manual explicitly distinguishes enabling from starting.

Do not make restart the whole troubleshooting procedure. A useful investigation records the failure, reads the relevant log entry, identifies a cause, changes one thing, and checks the result. A unit's active state is only one check; the application must also do its intended job.

Use Recover a Failed Service as a practice destination. The checkpoint is an explanation of the cause and evidence that the recovered service works. If the task includes persistence across reboot, verify that separately in an environment designed for it.

Trace a connection before changing the firewall

A running process does not guarantee a reachable service. Learn enough addressing, routing, DNS, and ports to separate the layers. On a Linux system with the relevant tools installed, start with read-only inspection:

ip addr
ip route
ss -ltn

These answer different questions: which addresses exist, where packets are routed, and which TCP sockets are listening. A loopback listener and a listener on an external interface have different reachability. A firewall is another boundary; opening a port cannot make a nonexistent listener appear.

For a lab-provided HTTP service, first test the intended local address and port, then the intended remote path. Check hostname resolution when using a name. A successful local request does not prove remote connectivity, and a failed ping alone does not establish that HTTP is unavailable.

Next learn SSH login, key-based authentication, and file transfer. Ubuntu's OpenSSH guide provides the client/server context and configuration guidance. Keep a working session available when an exercise changes remote-access configuration, and verify a new connection before relying on the change.

The checkpoint is to explain whether a failure concerns name resolution, routing, listening, filtering, or the application response. The course exercise Correct a Service Bind Address gives this stage a bounded practice target.

Automate a task and prove you can recover

Turn the log report into a Bash script only after you understand its commands. Give it an input-path argument, quote expansions, check missing or unreadable inputs, and return a nonzero status on failure. Practise conditions, loops, and functions as the task needs them; Shell for Beginners offers additional exercises in those areas.

Test an ordinary path, a path containing spaces, an empty log, and a missing file. ShellCheck's quoting explanation shows why unquoted expansion can change arguments through word splitting and globbing. Use the checker alongside execution tests. If you use an AI assistant to suggest a script, apply the same tests and explain the changes before adopting it.

Before scheduling backups, learn to inspect filesystem capacity with df and directory usage with du. Understand where the archive will be written and whether there is room for it. Partitions, LVM, and boot recovery can wait for a deeper administration track.

Back in the same practice directory, create an archive and restore into a separate location:

tar -czf service/backups/config.tar.gz -C service/config app.conf
tar -tzf service/backups/config.tar.gz
mkdir -p service/restore-check
tar -xzf service/backups/config.tar.gz -C service/restore-check
cmp service/config/app.conf service/restore-check/app.conf

For an unchanged source, cmp should produce no output and return zero. That checks the recovered file's contents. It does not establish a complete backup policy, off-machine protection, or application recovery.

Only then schedule the task using cron or, on an appropriate system, a systemd timer. Use explicit paths and capture failures: scheduled execution may not have the same working directory or environment as your interactive terminal. Verify an actual scheduled run, then restore a selected file. Restore a Configuration from Backup is a focused next exercise.

Choose a direction after the core checkpoints

The 2026 part of this roadmap is its checked environment and resource guidance, not a new set of Linux fundamentals. Course listings and platform defaults can change; use the documentation for the system you actually run.

For development, continue into Git, language environments, and containers. Your knowledge of paths, users, processes, ports, and logs gives you specific questions to ask when a containerized application fails.

For system administration, deepen storage, boot recovery, network configuration, and security policy. If you choose certification, map your skills against its current objectives. The RHCSA EX200 page currently specifies RHEL 10 and includes areas such as LVM and SELinux beyond this core route. This article is not an exam-coverage claim.

For security, continue with service exposure, access boundaries, and privileged automation. Linux Security for DevSecOps lists exercises in those areas. Learn to inspect the running system before attempting to harden it.

Before branching out, complete one small maintenance exercise without step-by-step instructions. In a disposable service lab, recover a broken configuration, verify the service's response at its intended address, generate an error report, and restore a selected file from backup. Keep a short record of the evidence, your change, and the verification. If you can explain all three, you have a concrete basis for the next stage.

References

LabEx Linux learning path — course and practice entry points; linked course syllabi were checked on September 7, 2026.
LPI Linux Essentials objectives and Linux Foundation Introduction to Linux — independent reference points for introductory scope.
Microsoft: systemd in WSL and Docker: containers and VMs — environment capabilities and boundaries.
GNU Bash pipelines and systemctl — pipeline status and service-management semantics.
Ubuntu package management and OpenSSH server — distribution-specific administration guidance.
ShellCheck SC2086 — word splitting, globbing, and quoting examples.
Red Hat EX200 objectives — the boundary between this general route and RHEL certification preparation.

Linux Journey, Rebuilt for Interactive Learning

Labby — Tue, 01 Sep 2026 07:26:26 +0000

The old Linux History page put almost everything on one screen: the lesson list on the left, the complete article in the middle, and exercises plus a quiz on the right. The material was available, but the learner had to decide how to move through it, where to pause, and whether one answer at the end was enough to check their understanding.

The new Linux Journey starts one level earlier. A course page now shows the sequence of lessons, a short outcome for each lesson, and one place to start or resume the course.

That visual redesign supports a more important change: Linux Journey is no longer organized only as a collection of pages to read. Each lesson now runs as a small learning sequence built around explanation, a decision, feedback, and continuation.

From a Syllabus to Learning Mode

The redesigned Getting Started course presents its 11 lessons as an ordered path. Each entry names the lesson and states what it covers, so a learner can see how Linux History leads into distribution choices and individual distribution guides before opening the first page.

Selecting Start Course opens the lesson in learning mode. Instead of displaying the entire page at once, the player begins with the first meaningful block and reveals the lesson step by step. A progress bar shows how far the learner has moved through the current lesson, while the Continue button provides a clear next action.

Course and lesson progress can be saved for signed-in learners. Signing in is not required to study the lessons; it is used to keep completion state available across devices.

Questions Become Part of the Explanation

The previous Linux History quiz asked one recall question after the article: who developed the Linux kernel? In the revised lesson, checks appear immediately after the ideas they depend on.

After the lesson explains that rewriting UNIX in C made it portable, for example, the learner chooses among three possible consequences. Selecting an option produces feedback for that specific choice. An incorrect answer explains the mismatch with the preceding material; the correct answer reinforces the portability principle. The lesson continues only after the learner identifies the correct answer.

These questions are comprehension checks, not claims that a learner has mastered Linux administration. Their job is narrower: interrupt passive scrolling at a useful moment and make the learner apply the explanation that just appeared.

The same player also provides a completion view with the lesson outcomes, a link to the next lesson, and a way to learn the lesson again. This turns the lesson boundary into part of the course flow instead of leaving navigation in a separate sidebar.

The Content Was Revised for the New Flow

The interface could not create this experience by itself. The Linux Journey lessons were also migrated to a structure that the player can divide into meaningful steps.

The revision preserved explanations, examples, images, and practice links when they were still accurate. It removed the old standalone exercise and quiz containers, moved useful material next to the topic it supports, and converted worthwhile questions into contextual single-choice checks. Each lesson now ends with a short summary of what the learner can explain or do.

Across the current lesson collection, every lesson in all nine supported languages contains four or five of these checks. Each option includes feedback, and each question must be answerable from material taught earlier in the lesson. The structure is designed to test the current idea without requiring unstated Linux knowledge.

The result is not a wholesale replacement of the original Linux Journey material. It is a new delivery structure for that material, with targeted revisions where a transition, explanation, or question needed to support the interactive sequence.

Still Free, Still Open

The redesigned Linux Journey remains free to use, with no payment or account required to read the lessons. Creating a free account is optional and enables saved learning progress.

The lesson content also remains open source in the official Linux Journey repository. It is published under the CC BY-SA 4.0 license, and the repository continues to accept community contributions to lessons and translations.

You can start with Getting Started, or inspect and improve the source material on GitHub.

Best Vibe Coding Tools in 2026: 12 Builders and Coding Agents Compared

Labby — Thu, 20 Aug 2026 00:59:53 +0000

The moment a Vibe Coding tool impresses me most is also when I become most cautious. One prompt can produce a polished app screen, but a polished screen is not a passed requirement. What changed, whether another person can take over, and where the project can recover after a failed build usually become visible only in the next round.

That is why I do not find a single ranking from first to twelfth useful. Replit, Lovable, Bolt, v0, Base44, and Google AI Studio are strongest when the job is to turn an idea into a running first version. Codex, Claude Code, Cursor, Windsurf, the GitHub Copilot app, and Google Antigravity make more sense when a project already exists and its files, commands, checks, and diffs need to be reviewed. The groups overlap, but their starting points remain different.

The question I want to answer is not “Which tool is best?” It is “At this stage of the project, which kind of workflow would I choose, and what evidence would I need before continuing?”

Two kinds of tools

I divide the products by their starting workflow, not by a permanent label attached to each brand.

An AI app builder combines a prompt, project setup, live preview, and usually hosting. It is a practical starting point when no project exists and the first need is a runnable user path with little setup.

An AI coding agent works more directly with project files, commands, tests, and version-control changes. It becomes more useful when a project already exists and the next decision depends on inspecting or changing that project within a controlled scope.

An inline code assistant is a third mode, but it is outside this comparison. Inline completion is valuable when someone is already writing code; it does not provide the same end-to-end path as a builder or project agent.

These modes are not levels in a progression from weak to strong. When an agent can touch more files and tools, I also have more to review. I usually start a bounded prototype with a builder and move to an agent only when the next task genuinely needs file-level control. AILesson's Vibe Coding for Beginners Course begins with the same distinction rather than prescribing a brand.

How I compared them

I used two evidence layers, checked on August 20, 2026.

Product-documented behavior comes from current official documentation, support pages, and release notes. It explains the workflow a product offers, but does not prove that the product completed our task.
Observed project evidence comes from a preserved build, test, change, or handoff record. It supports only the behavior that was actually checked.

Only the Replit-to-Codex path can be traced through the preserved Community Book Swap Checklist project used in the AILesson Course. For the other ten products, I reviewed current official workflows; I do not present documentation review as if I completed the same hands-on test in every product. A feature page can establish Git sync, checkpoints, or browser testing, but not that one tool would complete the brief better than another.

The observed project began with a bounded brief: build a mobile-first checklist with categories, completion state, filters, refresh persistence, a recoverable reset, and no real personal data. Its later coding-agent task was deliberately smaller: inspect one file-level dependency conflict, propose a bounded change, and preserve the existing application behavior.

The project record separates passed, partially passed, failed, and untested requirements. I will not turn one variable model run into a permanent quality ranking. I use it to set the comparison standard: running behavior, actual file changes, command output, recovery path, handoff state, and publishing boundary.

My shortlist

Start with Replit when you want one workspace for planning, building, Preview, checkpoints, files, and publishing—and you are prepared to test the result inside that workspace.
Start with Lovable or v0 when visual iteration is the main uncertainty and a Git-backed handoff matters.
Start with Bolt when the priority is a browser-based web build with immediate execution, code access, version history, and GitHub as an exit path.
Start with Base44 when built-in data, authentication, permissions, and hosting remove more work than platform dependence creates.
Start with Google AI Studio when Gemini capabilities, native Android generation, or Cloud Run deployment is central to the product rather than an incidental integration.
Start with a coding agent—Codex, Claude Code, Cursor, Windsurf, the GitHub Copilot app, or Google Antigravity—when a repository already exists and the next result must be a reviewable, testable change.

This is a starting shortlist, not a set of permanent lanes. Builders are adding repositories and editors; coding agents are operating browsers and producing visual evidence. I would still choose around the project's next unresolved problem, not stay loyal to a category.

App builders

If I have a bounded idea but no project, these are the six products I would inspect first. All reduce setup. What separates them is where the code lives, who owns the backend, how visual changes return to source, and what remains when the project leaves the platform.

Product	Best starting fit	Control and handoff	Main watchpoint
Replit Agent	A complete first app path in one workspace	Files, Shell, checkpoints, Git, export, and publishing	Preview success is not proof of a reproducible export
Lovable	Full-stack web apps with frequent visual refinement	Source-connected visual edits and two-way GitHub sync	Managed services still need a portability check
Bolt	Fast browser-based web and JavaScript projects	Code view, version history, branches, and GitHub sync	Token use grows with project size and iteration
v0	Design-led apps in the React and Vercel ecosystem	Full editor, production-like Preview, commits, and PRs	A strong first UI still needs behavioral testing
Base44	Apps that need data, login, permissions, and hosting	Code view; ZIP and GitHub export on eligible plans	More of the stack begins inside the platform
Google AI Studio Build	Gemini-first web or native Android apps	Live code editing, ZIP/GitHub export, Cloud Run deployment	Data services and usage costs need separate checks

Replit: everything in one workspace

Replit began as a browser-based coding environment and grew into a full-stack software-creation platform. Replit Agent, introduced in 2024, added natural-language app creation and deployment. I put Replit first among the builders not because it wins every feature, but because it keeps building, running, and recovery evidence close together—and because it is the only builder here backed by a complete observed project record.

Replit Agent documentation describes planning, building, testing, and checkpoints in the same workspace. That integration matters for beginners because a failed requirement can be checked against the running Preview, project files, Shell, and an earlier checkpoint without immediately moving the project elsewhere.

Agent can begin in Plan mode, then write across files, install dependencies, debug failures, and improve the app. Screenshots, files, and Canvas notes can supply visual or business context that a prompt does not express well. Replit also brings databases, authentication, Secrets, Git, and Deployments into the workspace, so a project can move from an empty starting point to a published app with persistent data without first assembling a local toolchain. Its checkpoints can cover code, Agent context, tasks, and connected database state rather than only a text diff.

Replit's official first-app documentation, accessed August 20, 2026. The screenshot identifies the Agent-and-Preview workspace; it does not establish that a generated app passed its requirements.

The Course run also exposed the limit of that convenience. A polished Preview did not prove a “no hidden external dependency” requirement. A file scan found unused Google Fonts links, and the focused export later proved reviewable but not independently buildable because workspace-level dependency information was missing. Replit was still useful; the evidence simply stopped short of reproducibility.

If I need to get one user path running quickly and am willing to test inside the workspace, I would start with Replit. I would not treat “Download source” as proof of reproducibility, however. Exporting files and rebuilding the same state on another machine are separate checks.

Lovable: visual editing with a managed backend

Lovable grew out of the open-source gpt-engineer project and its former commercial web product, GPT Engineer. It is now a natural-language full-stack web platform for non-technical builders and software teams. When my main uncertainty is “How many times will this interface change?” rather than “How should I design the architecture?”, Lovable makes my first shortlist.

Lovable keeps visual editing, full-stack services, and source handoff on one path. Visual Edits lets a user select an element in the running interface, adjust copy, color, and spacing, and write the result back to source. When the app needs dynamic data, Lovable Cloud provides a PostgreSQL database, authentication, Storage, Realtime, and Edge Functions; Supabase remains another supported route. Authenticated external APIs use Secrets and server-side functions instead of exposing credentials in the browser.

Its distinctive combination is visual selection plus two-way GitHub sync: a visual change does not remain an isolated mockup, and the code can enter a conventional branch and collaboration workflow. Publishing creates an explicit snapshot, so later editor changes do not silently replace the live version. Eligible Cloud projects can also separate Test and Live data and configuration.

Official Lovable Visual Edits article, March 13, 2025. It shows the visual editing surface, not the quality or portability of the resulting code.

New Lovable apps created since May 13, 2026 use TanStack Start with server-side rendering; older apps remain React and Vite projects, with different hosting requirements. I would keep Lovable for web apps with frequent visual change and an early need for login or data. If easy migration is a hard requirement, I would not stop after finding code in GitHub; I would trace how the database, users, files, and Secrets move as well.

v0: from interface generation to full projects

v0 is Vercel's AI development agent, originally known for generating React interfaces and components. It has since expanded into full-stack project work while retaining a design-first connection to Vercel. I would compare it directly with Lovable: both suit visual iteration, while v0's strongest path runs through React, GitHub, and Vercel.

v0 can turn text, wireframes, or screenshots into high-fidelity interfaces, then work on frontend code, API routes, and database integrations in a full VS Code-style editor. Design Mode lets a user select an element in the real Preview and adjust it with controls or natural-language instructions. Applying the edit creates a new project version, so the resulting source can be diffed, reverted, or refined.

Its Vercel and GitHub workflow is the defining feature. A Project shares deployments, domains, environment variables, and integrations across multiple chats. Once GitHub is connected, each chat works on a dedicated branch, code-changing messages create commits automatically, and the result enters main through a pull request rather than a direct push. Database integrations include Neon, Supabase, and Upstash.

Official v0 documentation, accessed August 20, 2026. This cropped screenshot locates Design Mode; use the resulting project diff—not the control itself—to judge the change.

When React and Vercel are already decided and the project depends on a landing page, dashboard, or precise UI, I would rank v0 highly. The same integration defines its boundary: an unusually direct Vercel deployment does not prove that another host needs no adjustment. I would still test forms, permissions, data, and failure states after the first screen looks right.

Bolt: the browser is the JavaScript runtime

Bolt.new is StackBlitz's AI app builder. It builds on WebContainers, a WebAssembly environment that runs a Node.js toolchain inside the browser instead of streaming a remote development machine. That is why Bolt deserves its own slot: the promise is not merely generated code, but code that can install, start, and fail visibly in the browser.

Bolt's quickstart places the prompt, code editor, browser runtime, and Preview in one path. Its central feature is the in-browser development runtime: the agent can create files, install npm packages, start a Node.js service, observe runtime failures, and continue fixing them without a local project setup. If the initial prompt explicitly requests a mobile app, Bolt can also produce an Expo-compatible project.

Bolt Cloud adds an automatically provisioned database, user authentication, Secrets, Edge Functions, and hosting, including a shareable bolt.host address. A database can also be claimed and managed through Supabase. Code View, version history, and the GitHub integration expose the implementation and provide a handoff path.

Official Bolt quickstart, accessed August 20, 2026. It shows the prompt-led starting point, not a completed task result.

I would use Bolt for a JavaScript or Node.js prototype when “run it now” matters more than merely receiving source. I would not treat it as a cloud IDE for arbitrary backend languages: PHP and Python are outside the documented runtime, and repeated iterations keep consuming tokens. I would settle the stack and budget before starting.

Base44: the backend is already there

Base44 is a natural-language app builder now operated by Wix. It resembles an integrated business-app platform more than a design-only generator: data, identity, backend logic, and hosting are present by default. I would reach for it when evaluating a CRM, internal tool, or membership app—not for a static landing page.

Base44's quickstart also begins with a prompt and live Preview, but its center of gravity is a ready-made backend for business applications. Its NoSQL database represents models as entities and supports realtime subscriptions plus row- and field-level permissions. Authentication covers email/password, common social providers, and SSO. Custom backend logic runs as Deno and TypeScript serverless functions.

Base44 divides integrations into several layers. Built-in actions generate text or images, send email, and process files; connectors use OAuth for accounts such as Google Workspace or Slack; custom integrations can be generated from an OpenAPI description and proxied through the backend so browser code never receives the credential. CRM tools, internal applications, member systems, and workflow-heavy apps make better use of these features than a static marketing page.

Official Base44 documentation, accessed August 20, 2026. The screenshot shows the chat-and-Preview layout; integrated services and export still require separate checks.

Its developer tools include a React/Vite code view, API Activity Monitor, GitHub workflow, ZIP export, and local-development path; built-in hosting supplies HTTPS and custom domains. I would inspect what “export” means here: moving the frontend and functions does not automatically move the database, authentication, integrations, or Base44 SDK. I would consider Base44 when the team accepts platform dependence in exchange for less setup, not when complete self-hosting is the first constraint.

Google AI Studio: when Gemini is the product

Google AI Studio began as Google's browser environment for experimenting with Gemini prompts. Build mode has expanded it into web and native Android development. I would not make it a general default simply because it can now build apps; its integration becomes distinctive when Gemini, native Android, or Cloud Run is already central to the product.

Google's current Build documentation makes AI Studio more than a playground for Gemini prompts. Web mode creates a React frontend and Node.js server runtime, supports npm packages and network-accessible databases, and places the Gemini API key in server-side Secrets. The Antigravity Agent manages changes across project files and verifies updates. A project can move to GitHub or a ZIP archive, or deploy directly to Cloud Run.

Android mode generates a native Kotlin and Jetpack Compose project with an in-browser emulator, physical-device installation, and a Play testing path. That is a meaningful distinction from most web-first builders. Android projects are currently client-side, however, so the server runtime and Secrets available to web apps do not transfer automatically.

Official Google AI Studio product image from October 2025. It shows the Build entry surface; the surrounding capability claims were rechecked on August 20, 2026.

I would seriously consider this route when Gemini text, image, or Live API behavior is the app itself, or when native Android and Cloud Run are explicit targets. A shared AI Studio app lets authorized recipients view and fork its code, their Gemini calls consume the creator's quota, and databases remain external services. I would verify “Gemini was easy to add” separately from “data, cost, and handoff are clear.”

When I switch to an agent

I would not move a project to a more technical-looking agent simply because two prompts failed. A tool change should resolve a specific control problem; otherwise it only moves the same vague request into a different input box.

In the Course project, the reason to move was concrete: the visible app could not settle a file-level dependency question. The working state was preserved, the relevant files were exported, and Codex was asked to inspect before editing. It proposed deleting exactly three unused font-related lines, while leaving application behavior and every other file outside the approved scope.

That Replit-to-Codex sequence is covered step by step in Vibe Coding for Beginners. Its value here is not promotional proof that those two brands win the comparison. It provides a real example of the threshold: switch tools when the next claim requires a different kind of evidence and control.

Coding agents

Once a repository exists, I expect more from an agent. “Task complete” carries little information. I want to see the plan, permission boundary, changed files, diff, command results, behavioral retest, and recovery path.

Product	Best starting fit	Review and recovery surface	Main watchpoint
Codex	Bounded or multi-step work in an existing local project	Plans, commands, checks, changed files, and diff review	Broad permissions require an explicit scope
Claude Code	Terminal-first repository work	Plan mode, permission modes, commands, tests, and Git	The operator must be comfortable reading command output
Cursor Agent	Agent work alongside everyday editor navigation	File-by-file diff review, selective acceptance, checkpoints	Checkpoints cover Agent edits, not permanent history
Windsurf Cascade	Editor-local work plus Windsurf 2.0 agent orchestration	Plans, tool calls, diagnostics, checkpoints, and reverts	The product surface now spans Cascade and Devin
GitHub Copilot app	Parallel local or cloud sessions around repositories	Interactive/Plan/Autopilot modes and isolated workspaces	Autonomy, isolation, and billing vary by run mode
Google Antigravity	Work that benefits from plans and visual proof	Reviewable artifacts, diffs, screenshots, and recordings	More artifacts help only when tied to requirements

Codex: work organized around reviewable changes

Codex is OpenAI's coding agent, designed to understand codebases, build and test features, fix bugs, and review changes. It is available across desktop, CLI, IDE, and cloud surfaces rather than being tied to one editor. In this comparison, I care less about the number of entry points than about keeping task scope, commands, and the final diff in one review chain.

The Codex workflow centers on editing files, running commands and checks, and reviewing the resulting diff. A local environment can work directly on the current working tree, a Git worktree can isolate parallel changes, and a cloud environment can hand a task to a remote sandbox. The integrated terminal and Review surface keep command output, changed files, and line-level diffs attached to one task.

Repository conventions and repeated procedures can be encoded in AGENTS.md, Skills, and Plugins so lint, test, documentation, or release rules do not need to be restated in every prompt. Permissions and sandbox settings govern which files, networks, and external tools the agent can reach. As that extension surface grows, the requested goal, protected areas, and acceptance commands need to become more explicit.

Course-prepared Codex desktop demonstration reconstructed from the preserved project and exact three-line diff. It shows the recorded review action, not the original execution screen.

In the Course record, what I could verify was not “the project is fixed,” but a bounded three-line deletion compared with the preserved original. I would consider Codex for a bug fix, refactor, test, review, or verifiable multi-step task in an existing repository. With only a product idea and no project structure, I would start with a builder instead.

Claude Code: terminal-first and highly extensible

Claude Code is Anthropic's agentic coding environment. It began in the terminal, with a harness that supplies project context, tools, permissions, and an execution loop, and now also spans desktop, IDE, web, and automation. If I already read shell commands and Git diffs comfortably and want to wire my own engineering rules into the agent loop, it feels more natural than a fixed builder interface.

Claude Code includes tools for file operations, code search, shell commands, Git, web lookup, and code diagnostics. Its loop gathers context, acts, and verifies. Plan mode limits exploration to read-only tools; Default and Auto-accept modes adjust which edits and commands require approval. A checkpoint taken before each file edit can be restored with double Esc or /rewind, but remote database, deployment, and API side effects are outside that recovery mechanism.

The product is more than a terminal chat pane. CLAUDE.md carries persistent project conventions, Skills package on-demand workflows, MCP connects external services, Hooks run deterministic scripts around tool and session events, and Subagents or Agent Teams move work into separate contexts. This is useful for teams already comfortable with CLI workflows and interested in wiring engineering rules into the agent loop. Each extension also adds context, permission, or maintenance overhead.

Official Anthropic product screenshot, accessed August 20, 2026. It identifies the terminal workflow; it does not verify a particular repository change.

I would not discount Claude Code because the terminal lacks a permanent visual Preview, or overrate it because the interface looks technical. The workflow works for me only if I can read proposed commands, inspect the Git diff, and distinguish local checkpoints from durable version history.

Cursor: a gradual path from completion to agents

Cursor is an AI-first code editor created by Anysphere. It began with codebase-aware chat, completion, and editing, then expanded toward foreground and cloud agents. Its most useful distinction is not simply that it “has an agent,” but that I can raise the autonomy level gradually—from completion to a focused edit to a larger delegated task.

Cursor's current workflow covers three different scales of assistance. Tab predicts multi-line and cross-file completions, Inline Edit changes selected code, and Agent searches the codebase, edits multiple files, runs terminal commands, and fixes errors. Ask mode is read-only, Manual mode only edits explicitly selected files, and Custom modes combine selected tools with specialized instructions. A developer does not have to start a high-autonomy task for every small change.

Review Diffs supports file-by-file inspection, Rules preserve project conventions, and MCP connects external tools. Checkpoints automatically save Agent-made file changes. For work away from the local machine, Background Agents clone a GitHub repository into an isolated Ubuntu environment, install dependencies, run tests, and push a separate branch; web, mobile, and Slack surfaces can start or follow those runs.

Official Cursor documentation image, accessed August 20, 2026. It shows the Agent review surface, not whether the displayed change is correct.

If I already read and change code in an editor and want to move gradually between completion and agent work, Cursor is a natural fit. Its local checkpoints cover only Agent changes, omit manual edits, and are cleaned up automatically, so I would not substitute them for Git. Because background environments have internet access and auto-run commands, I would review repository permissions, Secrets, and prompt-injection exposure separately.

Windsurf: the two-layer Cascade and Devin workflow

Windsurf is Cognition's agentic IDE, developed alongside the company's autonomous cloud agent, Devin. This explains its two-layer design: synchronous work with Cascade inside the editor, plus longer tasks delegated to cloud agents. That orchestration is attractive when I need to watch several tasks, but potentially excessive for one small repository change.

Windsurf 2.0 still begins with the editor. Cascade sits beside the codebase, plans tasks, searches and edits files, calls tools, reads diagnostics, and uses checkpoints and reverts when a change goes wrong. The editor offers models from several providers. Code Maps visualize relationships across files and symbols, while Preview lets web changes run in the same environment where they were made.

The defining 2.0 addition is Agent Command Center. Its Kanban view collects local and cloud agents, while Spaces organize sessions, pull requests, files, and context by project. A plan made with a local agent can be handed to Devin, which continues in its own VM with a desktop, browser, and terminal. Windsurf therefore serves both immediate editor pairing and longer background work instead of being only a chat panel beside code.

Official Cascade documentation image, accessed August 20, 2026. It locates the agent inside the editor; the current Windsurf 2.0 surface also includes broader Devin integration.

The local-Cascade and cloud-Devin combination is attractive when I need to move several tasks at once, but it also makes permissions and billing harder to read at a glance. Local editing, remote execution, model choice, and usage limits may not follow one set of rules. I would check checkpoint scope before restoring and confirm repository, network, and credential boundaries before a cloud handoff.

GitHub Copilot app: sessions inside the GitHub workflow

GitHub Copilot first became familiar as code completion inside an editor. The standalone GitHub Copilot app became generally available in June 2026, shifting the unit of work from a suggestion to a branch, issue, or pull request. I see its clearest audience not as every GitHub user, but as teams already organized around issues and PRs that now want several sessions running in parallel.

Each session can run in its own Git worktree, the current local repository, or a GitHub-hosted cloud sandbox, with a dedicated branch. Several tasks can progress without competing for one working tree, and an issue can move directly into implementation, diff review, commit, and pull-request work.

Interactive mode pauses for collaboration, Plan mode presents a plan for approval, and Autopilot can write code, run tests, and iterate without waiting. Each session can use a different model and reasoning effort; Auto selects a model based on the task, and external providers can be added with the user's own API key. An integrated terminal, browser tools, Quick Chat, and session history support execution and review.

Official GitHub announcement, June 17, 2026. It shows the standalone Copilot app, rather than inline completion in an editor.

If the code is already on GitHub and everyday work revolves around issues and pull requests, I would test the Copilot app early. Local worktrees, direct local folders, and cloud sandboxes still have different isolation, resource access, and cost boundaries. Autopilot can proceed without waiting; I would still perform the final review.

Google Antigravity: plans and screenshots as review artifacts

Google introduced Antigravity in November 2025 as an agent-first platform spanning the editor, terminal, and browser. Antigravity 2.0 added a standalone command center while retaining IDE, CLI, and SDK surfaces. It makes my shortlist not because it has many entry points, but because plans, diffs, screenshots, and recordings become commentable deliverables.

The standalone app centrally launches and monitors multiple local agents and scheduled tasks; Antigravity IDE lets agents use the editor, terminal, and browser. The distinctive comparison point is not the number of entry points but the way artifacts become part of the control loop.

Before coding, an agent can create an Implementation Plan and Task List that accept document-style comments. During implementation it produces code diffs, and after completion a Walkthrough describes the changes and tests. A browser subagent can click through the app and attach screenshots or a recording. Google's official Codelab also shows point-in-time Undo and the ability to send an IDE diagnostic or selected terminal failure to the agent.

Official Google Antigravity Codelab, accessed August 20, 2026. It shows a plan awaiting review; it does not prove the later implementation matched that plan.

I would shortlist Antigravity when UI behavior must be verified in a browser or when I want plan and visual evidence beside the source change. More artifacts do not automatically mean stronger proof, and some policies let an agent continue without waiting for Proceed. I would still map the plan, diff, screenshot, and recording back to the brief one by one.

What the price hides

I left monthly prices out of the main tables because they create false comparability. The products meter subscription access, messages, credits, tokens, model usage, compute, deployments, or some combination. A low advertised monthly price can still produce an interrupted run; a higher plan may include model or compute credit that another product bills separately.

Before choosing a plan, compare three facts instead of a single advertised monthly price:

the lowest plan that includes the workflow you need, such as full builds, Git export, background agents, or cloud sandboxes;
the unit that is actually metered—tokens, credits, messages, model calls, compute, or agent effort; and
separate hosting, database, model, or deployment charges that continue after generation.

Check the official pricing and checkout surface immediately before paying. A fair cost test records spend for your own bounded task; it does not assume that a plan with the lowest headline price will finish it.

Two tools I left out

I did not retain historically prominent tools after they lost their new-user path. Firebase Studio disabled new workspace creation and user signup on June 22, 2026, ahead of its March 22, 2027 shutdown, and directs new work toward Google AI Studio or Antigravity. Firebase's migration documentation makes it unsuitable as a new-user recommendation.

GitHub Spark also stopped accepting new users and new applications in August 2026. GitHub's current Spark documentation tells existing users to export their work. Both products may still matter in a history of the category, but neither should occupy a main comparison slot for someone choosing a tool now.

How I would choose

Your current situation	Start by testing	Why
You have a bounded idea but no project	Replit, Lovable, Bolt, v0, Base44, or Google AI Studio	The immediate question is whether you can obtain and test a complete running path with little setup.
The interface needs frequent visual refinement	Lovable, v0, or Bolt	Each offers a visual selection or design surface connected to the running project.
The app depends on integrated data, authentication, or hosting	Base44, Replit, Lovable, or Bolt	Integration may remove setup, but portability and public-access boundaries need explicit checks.
A repository already exists and the change is narrow	Codex, Claude Code, Cursor, Windsurf, Copilot, or Antigravity	The useful output is a scoped plan, reviewable change, checks, and a recovery path.
You prefer terminal work and can review commands	Claude Code or Codex CLI	The terminal can make project actions direct, but the operator owns the permission and command boundary.
You need visual artifacts of plans and browser verification	Antigravity, or another agent with equivalent recorded evidence	Plans, screenshots, and recordings can make review easier when they correspond to the actual requirement.

I would not declare an overall winner from this table. The same product can be sensible in one row and needless complexity in another. For a first project, I would shortlist two products from the same row, confirm that the needed feature is included in the current plan, and build one complete user path in each before expanding the scope.

If you want to practise that process before committing a real project, the AILesson Vibe Coding for Beginners Course follows one synthetic app from brief to Preview, focused repair, file inspection, bounded agent change, verification, and an honest non-public handoff. It stops where the evidence stops: the resulting demo is not described as production-ready, independently reproducible, or publicly deployed.

Whichever tool you choose, keep the same acceptance rule. A polished screen is a candidate result. Trust grows only when the behavior, changes, checks, recovery path, and handoff state are visible enough for you—or the next person—to inspect.

References

Replit Agent documentation — planning, testing, checkpoints, and the integrated workspace.
Lovable deployment and ownership documentation — managed services, GitHub code ownership, hosting, and migration boundaries.
Bolt introduction — browser-based building, databases, authentication, and hosting.
v0 FAQs — the 2026 editor, Git integration, projects, and Preview changes.
Base44 developer tools — code access, backend services, integrations, GitHub, and local development.
Google AI Studio Build documentation — current web and Android Build modes, export, and deployment paths.
Codex documentation — project understanding, changes, commands, checks, and review.
How Claude Code works — built-in tools, Plan mode, permissions, and checkpoints.
Cursor Agent documentation — completion, Agent tools, project context, and review workflow.
Windsurf 2.0 and Cascade documentation — the current editor, agent orchestration, planning, tools, checkpoints, and diagnostics.
GitHub Copilot app sessions — session modes, models, branches, and isolated workspaces.
Google Antigravity Codelab — product surfaces, browser actions, schedules, and artifact-led work.

Best Online Linux Terminals in 2026: Real Environments Compared

Labby — Wed, 19 Aug 2026 06:30:58 +0000

Running ls in a browser does not prove that Linux is running behind the prompt.

Some online terminals connect to an Ubuntu virtual machine. Some start a short-lived container. Others implement familiar commands in JavaScript without a Linux kernel, package database, service manager, or real process table. All three can draw a convincing prompt; only the first two execute commands on Linux.

That difference determines what you can practise. A command simulator may be enough to learn what cd does. Installing packages, managing users, inspecting processes, starting services, and diagnosing a changed system require a real Linux environment.

For learning Linux rather than administering a particular cloud account, LabEx Online Linux Terminal is the strongest option in this comparison. It provides an Ubuntu VM with sudo, several interfaces around the same system, guided labs, state checks, challenges, and contextual help. The terminal is also one entry point into a broader sandbox catalog and native LabEx apps for iPhone and Mac. Google Cloud Shell, AWS CloudShell, Azure Cloud Shell, GitHub Codespaces, and CoCalc are useful real environments built for different jobs. Coddy and WebTerm show why “runs in a browser” is not a sufficiently precise category.

What is actually running behind the prompt?

Execution model	What runs	Practical consequence	Example
Command simulator	Selected commands and a virtual file tree implemented in browser code	Useful for syntax practice, but there is no Linux kernel or arbitrary system software	WebTerm
Stateless Linux runner	A fresh server-side Linux container for each submission	Real Bash output, but files and directory changes disappear between runs	Coddy
Stateful hosted Linux	A remote Linux userspace retained for a session or project	Real files, processes, and packages within the service's permissions	AWS CloudShell, Azure Cloud Shell, CoCalc
Virtual machine	A complete Linux guest operating system provisioned on a server	Suitable for users, permissions, packages, processes, services, and networking	LabEx, Google Cloud Shell
Dev container on a VM	A project-specific container backed by a hosted VM	A repeatable development workspace tied to repository files and tools	GitHub Codespaces

A real system gives diagnostic commands real state to inspect:

uname -a
cat /etc/os-release
id
ps aux
ip addr

A simulator can return prepared text for some of these commands. It cannot expose an arbitrary package, daemon, kernel interface, or distribution-specific configuration that its developers did not implement.

Online Linux terminal comparison

The table focuses on the details that change what a learner can do. Startup speed is not scored because it varies with region, browser state, service capacity, and whether a remote environment is already warm. Product behaviour was checked against first-party documentation on August 19, 2026.

Platform	Backing environment	State	Elevated access	Learning support	Best fit
LabEx	Ubuntu VM plus Linux and tool sandboxes	Retained within the active lab workflow	Main Ubuntu VM: `sudo` for `labex`	Guided labs, checks, challenges, and contextual help	Learning Linux in a complete system
CoCalc	Hosted Linux project	Persistent project files and snapshots	No root	Course-oriented collaboration and shared terminals	Collaborative classes and computational work
Coddy	Fresh Linux container per Run	Stateless between submissions	Not intended for system administration	Command examples and related guides	Testing one Bash block without an account
WebTerm	Browser command simulator	Reset on page reload	Simulated commands only	Interactive command and Git tutorials	Learning basic syntax without an account
Google Cloud Shell	Debian-based VM with containerised workspace	5 GB persistent `$HOME`; session VM is temporary	Full root privileges and `sudo`	Product documentation	Google Cloud operations
AWS CloudShell	Amazon Linux 2023 compute environment	1 GB persistent `$HOME` per Region in public environments	Root inside the container and `sudo`	AWS tutorials	AWS operations
Azure Cloud Shell	Microsoft-managed Linux container	Optional Azure Files mount; otherwise ephemeral	No `sudo`	Azure training material	Azure CLI or PowerShell operations
GitHub Codespaces	Dev container on a dedicated Linux VM	Project workspace persists with the codespace	Root inside the dev container	Repository documentation and configuration	Cloud software development

Why LabEx ranks first for learning Linux

The LabEx Online Linux Terminal opens into an Ubuntu virtual machine rather than a fixed command simulator. The current VM documentation specifies Ubuntu 22.04, a labex user with sudo privileges, and three interfaces connected to the same environment:

Terminal for direct command-line work;
WebIDE for editing files in a VS Code-like interface;
Desktop for graphical applications and visual file operations.

Terminal, WebIDE, Desktop, and web preview expose different views of the same Linux environment. Screenshot from the Online Linux Terminal.

The shared VM matters more than the number of tabs. Create a file in the terminal and the WebIDE can edit that same file. Start a web service and the preview can open it. Change permissions and the next command sees the changed modes. The learner is operating one system whose state continues across actions.

LabEx also gives that system a learning loop. Your First Linux Lab introduces the environment through commands and step checks. In Guided Labs, verification tests whether the VM reached the required state. The Labby documentation describes debugging and concept clarification inside the active lab workflow.

The interface can change while the current lab environment remains in place.

That produces a concrete progression:

Read the task beside a prepared Linux system.
Run commands and inspect their effects.
Check whether the required state exists.
Diagnose a failed check and retry.
Move to a Challenge that states the objective with less procedural guidance.

The Linux learning path continues from command-line basics into shell scripting, system administration, security, projects, and challenges. A blank cloud shell can run many of the same commands; it does not supply this sequence or check what the learner changed.

Beyond one Ubuntu VM: LabEx Playgrounds

The main Online Linux Terminal uses Ubuntu, but LabEx is not limited to one distribution or one terminal configuration. The LabEx Playgrounds catalog currently lists 52 browser-based sandbox environments.

The Linux section includes Ubuntu, Ubuntu Desktop, Debian, Alpine, CentOS, RHEL, Fedora, Arch Linux, and openSUSE. Other categories provide prepared environments for tools and workloads such as Kali Linux, Docker, Kubernetes, Ansible, databases, programming languages, and AI coding agents. This lets a learner move from a general Linux terminal into an environment chosen for the next task without configuring it locally.

The Linux section of LabEx Playgrounds provides several distributions rather than a single Ubuntu entry point.

The useful distinction is between the environment and the lesson layered around it. A Playground supplies a prepared sandbox for open exploration. A Guided Lab adds instructions and checks. A Challenge states the objective with less procedural help. The learner can therefore choose both the Linux environment and the amount of guidance required.

Use the online Linux terminal in the iOS and macOS apps

The browser is not the only client. LabEx also provides native apps for iPhone and Mac. The LabEx App VM documentation says the app attaches a remote VM to the current lab, while instructions, Labby, and checks remain in the learning interface.

On iPhone, the VM opens in a sheet that can move between medium and large heights. The sheet shows setup progress and remaining session time, then provides terminal actions, interface switching, VM controls, and exposed ports. This makes it possible to start or resume terminal-based lab work from iOS without turning the phone into the machine running Linux.

The iPhone app keeps the lab instructions visible while the remote Linux environment starts.

On macOS, the terminal is embedded in a wider learning workspace. Terminals and exposed ports appear in the sidebar, while the current instructions, assistant, and verification result can remain visible beside the shell. The same split that matters in the browser remains intact: Linux runs in the remote environment; the app provides a native interface to operate it.

The macOS app places the real terminal beside the current lab context and verification controls.

LabEx adds more structure than a one-box runner, so it is not the quickest choice for checking whether one pipeline parses. It fits when the next question is “Did I change the Linux system correctly?” rather than only “Did this command produce output?”

How the other real Linux environments differ

CoCalc: persistent Linux projects and collaboration

CoCalc's online Linux terminal runs remotely and keeps project files with snapshots. Its distinguishing feature is real-time collaboration: several users can open a synchronized terminal and work beside a chat panel. That is useful for teaching a class or sharing computational work.

CoCalc documents two boundaries that matter here. Users do not receive root access, and outbound internet access in a free project requires a license. It provides a real, persistent Linux project, but it is organised around collaboration and a broad scientific software stack rather than a checked Linux learning path.

Google and AWS Cloud Shell: real Linux for cloud operations

Google Cloud Shell provisions a temporary Compute Engine VM running Debian-based Linux. The default workspace is a container on that VM. Users have sudo, while a 5 GB persistent $HOME survives after the session VM is discarded.

AWS CloudShell provides an Amazon Linux 2023 compute environment with AWS credentials from the current console session. AWS documents 1 vCPU, 2 GiB of RAM, sudo, root access inside the container, and 1 GB of persistent home storage per Region for public environments.

Both are capable Linux shells. Their pre-authenticated cloud context is an advantage when the task is gcloud or AWS CLI work. For a Linux beginner, that same context introduces projects, IAM, Regions, quotas, and cloud-resource permissions that are unrelated to learning chmod, package management, or service diagnosis.

GitHub Codespaces: a terminal inside a development workspace

GitHub Codespaces assigns a dedicated Linux VM, clones a repository into /workspaces, and creates a Docker development container. It combines the terminal with browser-based VS Code, port forwarding, repository settings, and repeatable devcontainer.json configuration. Root access is available inside the dev container.

That makes Codespaces the better choice when the repository and editor are part of the task. It is a larger conceptual starting point for command-line practice: the user may encounter repository ownership, machine sizes, containers, ports, commits, and usage accounting before those concepts belong in the lesson.

Azure Cloud Shell: convenient, but deliberately restricted

Azure Cloud Shell offers Bash or PowerShell with Azure tools already configured. Sessions time out after 20 minutes of inactivity. Persistent files require an Azure Files mount; without one, the session is ephemeral.

Microsoft documents the user as unprivileged: sudo and other elevated commands are unavailable. That boundary is reasonable for a managed Azure console, but it prevents system-administration exercises that install protected packages, create users, modify system configuration, or manage services as root.

Where instant runners and simulators fit

Coddy executes real Bash and GNU tools in a server-side Linux container without requiring an account. Every Run starts in a fresh /home, so a pipeline or multi-line script works, but a standalone cd, created file, or environment variable cannot affect the next submission. It is useful when the whole task fits in one command block.

WebTerm Free Play takes the browser-only approach. Its virtual file tree, pipes, redirection, Git workflows, and implemented commands support basic practice without registration. WebTerm also states that it is a simulator rather than a virtual machine. Reloading resets the environment, and there is no Linux backend on which to install an arbitrary package or inspect a real service.

These tools are not defective versions of a VM. They solve smaller problems with less startup and account friction. The mistake is treating their terminal-shaped interfaces as evidence that they can reproduce system administration on Linux.

Choose by the task behind the terminal

Use LabEx to learn Linux through real remote environments, checked tasks, and progressively reduced guidance, with additional Playgrounds and native iPhone and Mac access when the workflow needs them.
Use CoCalc when several people need a persistent shared terminal or a broad computational software stack.
Use Coddy to test one self-contained Bash block without creating an account.
Use WebTerm for browser-only command syntax and Git tutorials, with the simulator boundary in mind.
Use Google Cloud Shell, AWS CloudShell, or Azure Cloud Shell to operate resources in the matching cloud account.
Use GitHub Codespaces when a repository, editor, dev container, and terminal should form one development workspace.

For a first session on an actual Linux system, open Your First Linux Lab. Run whoami, uname -a, ps aux, and cat /etc/os-release; then make a change and use the lab check to verify the resulting state.

References

LabEx Online Linux Terminal, Virtual Machine documentation, and Labby documentation — environment model, interfaces, privileges, checks, and contextual help.
LabEx Playgrounds — current Linux distributions and the broader catalog of sandbox environments.
LabEx App overview and VM and terminal documentation — supported Apple platforms, remote VM controls, terminals, forwarded ports, and learning layout.
CoCalc Online Linux Terminal — remote Linux environment, collaboration, persistence, root, and network boundaries.
Coddy Online Linux Terminal — server-side Linux execution and stateless runs.
WebTerm Free Play — simulator model, implemented workflows, and reset behaviour.
Google Cloud Shell architecture — VM, container, privileges, lifecycle, and persistent storage.
AWS CloudShell overview, environment specification, and security FAQ — Linux image, resources, storage, and root boundary.
Azure Cloud Shell features and FAQ — persistence choices, timeout, and privilege restrictions.
GitHub Codespaces technical overview — VM and dev-container model, repository lifecycle, interfaces, and privileges.

KodeKloud vs LabEx: Which Hands-On Learning Model Fits You?

Labby — Thu, 13 Aug 2026 00:20:20 +0000

Open a beginner Linux course on KodeKloud and you may meet an instructor, a fictional workplace, a quiz, and then a terminal lab.

Open the comparable course on LabEx and the lesson begins beside the environment where you will run the commands.

Both platforms lead to hands-on work. They differ in what they put before it, what happens when a check fails, how they remove guidance, and how completed practice becomes evidence of a skill.

That makes “Does it have labs?” a poor way to compare KodeKloud and LabEx. Both do. A more useful question is which learning loop helps you move from following an explanation to solving a system problem without one.

The useful comparison is not whether either platform has labs. It is what the platform can understand about your work when the expected result does not appear.

The Short Version

If you want to...	Start by looking at...	Why
Learn from instructor-led videos before practicing	KodeKloud	Its courses commonly combine narrated lessons, quizzes, stories, and browser labs.
Prepare for CKA, CKAD, CKS, or another named certification	Either, with different formats	KodeKloud emphasizes video-led courses and mock exams; LabEx organizes hands-on prep and practice exams inside certification Skill Trees.
Learn mainly by reading and operating the environment	LabEx	Its default format is no-video, with instructions, a VM, and verification in the same workflow.
Get feedback based on the current lab and your recent actions	LabEx	Labby works with the active lab context, while Deep Inspection can review operation logs after a failed verification.
Move from guided practice to minimally guided problems	Either, with different structures	KodeKloud offers Engineer tasks and challenge programs; LabEx places Guided Labs and Challenge Labs inside its course and Skill Tree model.
Track progress as evidence against individual technical skills	LabEx	Labs, challenges, projects, and assessments can contribute evidence to concept-level skills rather than only course completion.
Keep labs, AI help, solutions, and projects in one lower-cost plan	LabEx	LabEx Pro lists these together at $99.90 per year; KodeKloud distributes advanced practice and AI across higher subscription tiers.

This is not a ranking. A learner preparing for a certification may prefer KodeKloud's instructor-led sequence or LabEx's no-video, lab-first route. Someone who routinely skips course videos may reach the terminal faster with LabEx even when both catalogs cover the same command.

Before the Terminal: Two Ways to Introduce a Topic

KodeKloud: Explain, Then Practise

KodeKloud's Linux Basics course shows its teaching pattern clearly. It mixes videos, a continuing story about a fictional company, multiple-choice questions, articles, and labs.

A section on the shell includes video lessons before the corresponding terminal exercises. Later sections repeat the pattern for package management, the Linux kernel, networking, storage, and service management.

The browser lab is not an optional appendix. KodeKloud says each lecture is followed by a hands-on lab where it validates the learner's work and provides feedback or hints.

Typical rhythm: watch → answer → practise → receive feedback.

KodeKloud's public Linux course page presents modules beside video length, story format, and lab access.

LabEx: Explain Inside the Practice

LabEx starts from a different constraint. Its support documentation describes the platform as no-video and organizes instruction around browser environments with automated checks. In Quick Start with Linux, the course sequence contains five Guided Labs and five Challenges. The learner reads the explanation while working in the environment rather than watching a lecture before opening it.

Typical rhythm: read → operate → check → retry.

LabEx's course syllabus places guided labs and challenge activities in one sequence; the two activity types use different icons.

Different routes, same destination: the meaningful work still happens in a running environment.

Neither sequence is inherently more rigorous:

Video before the lab can make architecture, process, and visual relationships easier to introduce.
Text beside the terminal makes it easier to pause on a command, inspect the current state, and retry without moving between a player and a lab.

The useful distinction is the amount and form of explanation you want before touching the system.

A Passing Check Is Only the Beginning

Both platforms remove much of the setup work that can consume a beginner's study session. In either one, a learner can:

open a prepared environment in the browser;
run commands and change configuration;
submit the resulting state to automated checks;
retry without first rebuilding a disposable Linux or Kubernetes machine locally.

Both also check work rather than treating terminal activity as proof by itself. KodeKloud's Linux course describes labs that validate answers and return feedback. In LabEx, a Guided Lab runs a verification script against the VM after a step.

Running chmod does not establish that the resulting permissions are correct. A useful lab checks the state that the command produced.

This shared mechanism matters more than catalog slogans. The learner has to connect a command, its effect, and the requirement the checker is enforcing. But a deterministic script usually answers only one question: does the current state satisfy the rule it was written to test?

LabEx Adds Context to a Failed Check

Labby is connected to the active lab workflow rather than operating as a detached chatbot. LabEx's documentation says that step verification runs inside the VM. The current Your First Linux Lab goes further: its Ask feature understands the current lab context and recent actions, so a learner can ask where a mistake occurred, request a learning report based on the session, or ask how to improve.

The same lab contains a deliberately failed verification after the learner runs id -un. Clicking Re-Inspect triggers Deep Inspection, which uses AI to review the operation logs. It can then give feedback tied to what the learner actually did instead of repeating a generic hint for everyone who failed the same step.

Verification script — state inside the VM: produces a deterministic pass or failure.
Deep Inspection — failed check and operation logs: provides a contextual diagnosis and a more relevant next action.
Ask Labby — question, current lab, and recent actions: provides targeted explanation, debugging help, or session feedback.

Labby remains inside the learning workflow, with actions for asking questions, debugging, explaining code, and returning to the running lab. Image from the LabEx AI Assistant documentation.

This does not make every diagnosis infallible. A verification script can be too narrow, and an AI inspection can misread an unusual sequence of actions. The advantage is the additional evidence available when a plain pass/fail result is not enough.

The distinction appears again in how the environment is presented. KodeKloud offers course labs as well as open DevOps and cloud Playgrounds for experiments without predefined instructions. A LabEx VM can expose a Linux desktop, WebIDE, or terminal depending on the task. These are different interfaces around the same important idea: the learner should change a running environment, not only recall an answer.

What Happens When the Instructions Stop?

A guided lab can confirm that you followed a procedure. It cannot, by itself, show whether you would recognize when to use that procedure.

KodeKloud Engineer: The Task as a Work Ticket

KodeKloud addresses that gap most visibly through KodeKloud Engineer. The program places the learner in a fictional organization, provides project documentation and systems, and assigns operational tasks.

The surrounding fiction gives each task the shape of a work ticket rather than another chapter in a course. KodeKloud's Engineer 2.0 overview lists tasks in Linux, Git, Docker, Kubernetes, Jenkins, and Ansible.

LabEx Challenge: The Task as a Skill Check

LabEx uses Challenge Labs for the same transition from instruction to application. A Challenge usually keeps the objectives and requirements but removes most explanatory steps. The learner must inspect the supplied state, decide which commands or files matter, make the change, and satisfy the checks.

Independent-practice model	KodeKloud Engineer	LabEx Challenge
Context	Fictional organization and operational task	A stated objective in a prepared technical environment
Connection to learning	A distinct job-simulation experience	Linked to courses and concept-level Skill Trees
Likely appeal	Learners who value workplace narrative	Learners who want a direct concept-to-check loop

The transition that matters: follow less, decide more, then verify the resulting state.

Neither should be described as employment or production experience. The systems are controlled learning environments. Their value is that they can expose a gap hidden by step-by-step completion: knowing a command is different from diagnosing when and how to use it.

Certification Preparation Is No Longer a One-Sided Comparison

Certification preparation is a traditional KodeKloud strength. Its CKA Learning Path, for example, moves through Linux, containers, Kubernetes, a dedicated CKA course, and mock exams. The same catalog has named paths for CKAD and CKS. This is a clear fit for learners who want an instructor-led course sequence ending in exam-shaped practice.

LabEx now covers much of the same certification decision. Its public Skill Trees catalog lists CKA, CKAD, and CKS training alongside RHCSA, RHCE, LFCS, and CompTIA Linux+, A+, Network+, and Security+ preparation. For each of CKA, CKAD, and CKS, the catalog groups three courses: a preparation course and two practice-exam courses.

The distinction is therefore less about whether certification content exists and more about how it is delivered:

Certification-prep question	KodeKloud	LabEx
How is the syllabus introduced?	Instructor-led video courses followed by labs	No-video explanations beside live environments
How does exam practice appear?	Dedicated certification courses, readiness tests, and mock exams	Hands-on prep courses and practice exams inside certification Skill Trees
What does progress connect to?	A course and certification learning path	A certification path plus reusable Kubernetes, Linux, and security skills

Neither platform awards the CKA, CKAD, or CKS credential itself. Those credentials still come from the certification body after the learner passes its exam. The platforms provide preparation, labs, and practice exams; their course-completion certificates are a separate record.

Course Progress and Skill Evidence Are Not the Same Thing

KodeKloud's Learning Paths answer a planning question: which courses should someone take for a domain, certification, or role? The current catalog includes domain paths for Linux, Kubernetes, cloud platforms, infrastructure as code, and AI, as well as role paths for system administrators, DevOps engineers, platform engineers, and other infrastructure roles. Course certificates, readiness tests, and KodeKloud Engineer progression provide several ways to represent work completed inside those paths.

LabEx also has courses and certificates, but its Skill Trees add a separate layer. A Skill Tree is a map of the capabilities inside a technical domain, not merely another order in which to consume lessons.

The relationship is many-to-many: one lab can teach or assess several skills, while one skill can receive evidence from several Guided Labs, Challenge Labs, projects, or assessments. This matters for learners who do not follow one linear course from the beginning. Existing ability in file operations can remain distinct from gaps in Linux services, networking, or process management.

The Skill Tree structure connects a domain to reusable skills and then to the labs that practise them. Image from the LabEx Skill Trees documentation.

The public Skill Trees V2 catalog makes the structure inspectable outside the product UI. It defines domain boundaries, stable skill identifiers, names, descriptions, and canonical ordering. Each skill is intended to represent a reusable concept-level capability rather than one command option or one step in one lab.

That distinction changes what a progress page can answer:

Course completion: Did the learner reach the end of this sequence?
Skill evidence: Which concepts did the completed work exercise across courses, challenges, projects, or assessments?

The second view can reveal that finishing one course did not exercise every skill in the tree. It can also combine evidence from different courses when they exercise the same underlying capability.

The careful word here is evidence, not proof of job readiness. A completed LabEx challenge records performance inside that challenge's environment and checks. It does not establish how someone will perform in every unfamiliar system. The Skill Tree makes the platform's interpretation visible; it does not remove the limits of platform-based assessment.

Price Changes the Practical Comparison

Price is volatile, but omitting it would hide one of LabEx's clearest advantages. As of August 12, 2026, LabEx Pro is listed at $99.90 per year. That plan includes 6,000+ hands-on labs, unlimited virtual machines, 2,000+ challenge solutions, 400+ projects, completion certificates, and full access to Labby.

KodeKloud's pricing is regional and promotion-dependent, so its checkout price should be checked directly. Its feature split is still useful to compare: Standard includes the main course library and 1,280 hands-on labs; Pro adds playgrounds, cloud labs, projects, and unlimited KodeKloud Engineer work; the AI tier adds the personalized tutor and AI-assisted labs.

What you need	LabEx	KodeKloud
Free hands-on access	3 VMs per day	Limited free courses and features
Unlimited core labs	Included in Pro	Included in Standard and above
AI assistance in the learning workflow	Full Labby access in Pro	Personalized tutor and AI-assisted labs in the AI tier
Challenges, solutions, and projects	Included in Pro	Access and task limits vary across Standard, Pro, and AI

The value advantage is not just a lower headline price. A learner who wants labs, project and challenge practice, solutions, and contextual AI help can obtain that bundle in one LabEx Pro subscription. The products are not feature-for-feature identical—KodeKloud also funds a large instructor-led video catalog—so the fair conclusion is narrower: for learners primarily buying hands-on practice and AI-assisted feedback, LabEx offers the stronger all-in price.

Which Platform Fits Your Learning Loop?

Start With KodeKloud If...

You want an instructor-led DevOps or cloud curriculum.
You want instructor-led certification preparation with a long-established video and mock-exam sequence.
A role-based sequence helps you decide what to learn next.
Workplace narrative makes independent tasks more engaging.

Its videos and labs are designed to support each other, and KodeKloud Engineer provides a distinct place to practise ticket-shaped tasks after learning the foundations.

Start With LabEx If...

Video is the part of online learning you usually skip.
You prefer reading instructions beside a live environment.
You want AI help that can use the current lab, recent actions, and failed verification context.
You want a direct progression from Guided Labs to Challenges.
You want progress represented as concept-level skill evidence across courses.
You want hands-on certification paths and AI-assisted practice in one lower-cost annual plan.

The default interaction is reading, operating a VM, checking the result, and moving from guidance to a less-prescriptive problem.

Topic coverage can change the answer. KodeKloud's public catalog is strongly developed around DevOps, Kubernetes, cloud, platform engineering, certification preparation, and newer AI topics. LabEx exposes learning directions beyond infrastructure, including programming languages, databases, data science, web development, and cybersecurity. A larger category list does not establish depth, so compare the actual course and challenge sequence for the subject you intend to study.

Compare the actual course and challenge sequence, then compare the plan that unlocks the features you will use. A low entry price is less informative than the total cost of labs, AI help, solutions, and independent practice.

A 30-Minute Test Before You Choose

Use the same small Linux topic on both platforms. File permissions, process inspection, or package management works better than comparing two unrelated flagship courses.

Measure time to terminal. Start a free beginner lab and note how long it takes before you run the first meaningful command.
Make a reversible mistake. Check whether the feedback merely states the expected answer or can explain the failure using what you actually did. In LabEx, compare the initial check with Re-Inspect and an Ask Labby question.
Remove the procedure. Complete one guided task, then find a Challenge or Engineer task covering related skills.
Inspect the evidence. Can you tell what capability was exercised and what remains, or only that the activity is finished?
Choose for your real habits. Prefer the balance of explanation, terminal time, feedback, and independent work that matches how you actually study.

The better platform is the one that gets you from a correct walkthrough to an unfamiliar system state with enough support to recover, but not so much that the decisions have already been made for you.

Display User and Group Information Challenge Solution

Labby — Thu, 09 Jul 2026 00:56:34 +0000

The LabEx challenge Display User and Group Information is short, but it tests an important Linux reflex: before reasoning about permissions, confirm which user the shell is running as and which groups that user belongs to.

Unlike a guided lab, this is a challenge. The page gives the required outcome, but it expects you to choose the commands yourself. The solution comes from matching each requirement to the Linux command that reports exactly that information.

Problem Summary

The challenge has two tasks:

Display the current user identity.
Display detailed user and group information, including uid, gid, and groups.

That means the answer needs two levels of identity information. The first task only wants the username. The second task wants the numeric and named identity fields Linux uses for access decisions.

Step 1: Print the Current Username

For the first task, use whoami.

whoami

The expected output is only the current username. In the LabEx environment, it may look like this:

labex

This command answers a narrow question: "Which user am I right now?" It does not show groups, IDs, or permission details. That is why it is the right command for the first requirement, but not enough for the second one.

Step 2: Print User and Group Details

For the second task, use id.

id

The output should include the user ID, primary group ID, and supplementary groups:

uid=1000(labex) gid=1000(labex) groups=1000(labex),4(adm),24(cdrom),27(sudo)

The exact numbers and group names can differ between environments. What matters is the structure:

uid=1000(labex) means the current user has numeric user ID 1000 and username labex.
gid=1000(labex) means the primary group ID is 1000 and the group name is labex.
groups=... lists every group membership available to the current user.

Why These Commands Solve the Challenge

whoami solves the first requirement because it prints only the current username. If the challenge asks for a single user identity, this is the cleanest output.

id solves the second requirement because it includes the fields named in the prompt: uid, gid, and groups. You do not need to inspect /etc/passwd or /etc/group for this challenge. Those files can explain account configuration, but the task asks for the identity information of the current session, and id reports that directly.

The common mistake is to stop after whoami. That confirms the username, but it does not prove group membership. In Linux permission checks, group membership can be the difference between access granted and access denied.

Final Answer

Run these two commands:

whoami
id

You have completed the challenge when the first command prints the current username and the second command prints identity details containing uid, gid, and groups.

Learn Linux Through Operational Challenges

Labby — Wed, 08 Jul 2026 04:15:53 +0000

Many Linux beginners can remember a command before they know where it belongs. They can run touch, chmod, ss, or systemctl, but still hesitate when a task has a working directory, an existing file, a service that must stay running, and a specific result to verify.

That gap is where command practice starts to become operational practice.

The contrast is simple: a command list teaches syntax, while an operational challenge forces the command to answer a real constraint.

100 Days of Linux is built around that gap. The course is not a list of 100 unrelated commands. It is a sequence of 100 small Linux challenges, each framed as a task with context, scope, a required final state, and acceptance criteria.

The first challenge is intentionally small. In "Claim the Drop Folder", the learner starts in /home/labex/project, finds an existing drop-folder/incoming directory, and creates a ready.flag file in that exact location. The command may be as simple as touch, but the real lesson is not the command name. The learner has to confirm the working directory, avoid creating the marker in the wrong place, and leave the existing folder structure intact.

That pattern repeats across the course: a command is useful only when it changes the right thing and leaves the rest of the system alone.

The syllabus makes the progression visible. The first ten days focus on handoffs: claiming a folder, inventorying a delivery, reading a welcome note, preparing a review folder, and closing the first handoff. The next sections move through reading operational evidence, safe file changes, access boundaries, running work reliably, local app validation, tooling, managed services, recovery, and final operations simulations.

That structure gives the command a job. A checklist can tell a learner that chmod 600 file restricts a file to its owner. A challenge can make that command matter by placing it inside a specific handoff: a private manager note already has the correct content, but its mode is too open. The task is to change the permission while preserving the file and its contents.

The same approach works for networking and services. In one local app validation challenge, the learner must identify which candidate TCP port is actually listening by inspecting local sockets with a command such as ss -ltn, then copy only the matching port card into a review folder. The service must remain running. The final state matters as much as the inspection command.

Later tasks add more moving parts without turning into vague troubleshooting exercises. A maintenance challenge asks the learner to schedule a prepared heartbeat script with cron and confirm that the expected output file appears. A recovery challenge asks them to inspect mounts under /mnt, locate a staged recovery card, copy it into the project intake folder, and leave the mount available.

By the final day, the task has become a compact incident. The learner must close a broken local status API by reading service evidence, fixing config access for the labex service user, clearing stale process state, starting labex-status-api.service, and verifying that http://127.0.0.1:18200/health returns the expected status lines. That is still beginner-scoped, but it is no longer isolated command recall.

Across these examples, the same small loop keeps coming back.

The useful habit running through the course is constraint-aware work:

Know the current workspace before changing files.
Read the existing structure instead of recreating it.
Preserve content when the task is only about permissions or placement.
Inspect evidence before acting on a service or port.
Verify the final state with the same precision as the task description.

Those habits are hard to build from reference material alone. They come from repeated small tasks where a wrong directory, an extra copy, a deleted file, or an unverified service changes the outcome.

For someone who has already learned basic commands but still feels slow in a Linux terminal, the first useful step is not another command list. Start with the early handoff challenges in 100 Days of Linux, then move into the permissions, service, and recovery sections once the basic file tasks feel routine.

Linux Journey Is Now Part of LabEx

Labby — Mon, 08 Jun 2026 01:38:17 +0000

Linux Journey has been one of the most popular free resources for learning Linux since 2015.

Created by Cindy Quach, the project has helped millions of beginners take their first steps into Linux through simple lessons and quizzes.

Today, Linux Journey is officially part of LabEx.

The original Linux Journey website (https://linuxjourney.com) now redirects to https://labex.io/linuxjourney.

Our goal is straightforward: keep Linux Journey free, open source, and actively maintained for the next generation of Linux learners.

We'll continue maintaining existing lessons, fixing issues, improving translations, and adding new beginner-friendly content over time.

The official repository is now maintained by the LabEx team:

https://github.com/labex-labs/linuxjourney

We've also recently launched the Linux Journey iOS app, making it easier to learn Linux on the go:

https://apps.apple.com/app/linux-journey/id6770861660

Most importantly, nothing changes about what made Linux Journey special.

It remains free. It remains open source. It remains community-driven.

A huge thank you to Cindy Quach and all contributors who helped build Linux Journey into one of the most loved Linux learning resources on the internet.

We're honored to continue the journey.

Master Git: How to Undo Commits, Switch Branches, and Manage Tags Effectively

Labby — Sun, 07 Jun 2026 17:27:55 +0000

Every developer has been there: a messy commit history, confusion over branch switching, or the need to mark a release milestone. Git is the backbone of modern software development, but mastering it requires more than just memorizing commands. This learning path takes you through three practical scenarios that turn Git from a daunting tool into your most reliable project assistant.

How to Undo and Remove a Specific Git Commit from Current Branch

Difficulty: Beginner | Time: 15 minutes

Learn how to undo and remove a specific Git commit from the current branch. Discover the best practices for managing Git commit history and restoring removed commits.

Practice on LabEx → | Tutorial →

Git Switch vs Git Checkout

Difficulty: Beginner | Time: 30 minutes

Explore the differences between Git switch and Git checkout commands, learn when to use each, and master your Git workflow. Practical examples and use cases included.

Practice on LabEx → | Tutorial →

Tagging Your Project's History

Difficulty: Beginner | Time: 5 minutes

Learn how to use Git tags to mark important milestones in your project's history. Practice creating lightweight and annotated tags, and listing tags in a repository using a time machine software project scenario.

Practice on LabEx → | Tutorial →

Git mastery isn't about memorizing every flag in the manual; it is about understanding how to manage your project's evolution. By completing these three labs, you move from simply 'using' Git to 'commanding' it. Ready to level up your version control skills? Dive into these interactive exercises today and start building a cleaner, more professional development history.

4 Wireshark Labs: Master Network Analysis, Nmap Scanning, and Metasploit Exploitation

Labby — Sat, 06 Jun 2026 17:24:35 +0000

Ready to see what is really happening on your network? Wireshark is the gold standard for packet analysis, and we have built the perfect roadmap to take you from zero to hero. Forget boring videos—our hands-on labs put you in the driver's seat of a real network environment. Let's dive into the packets!

Use Nmap and Metasploit for Network Scanning and Vulnerability Analysis

Difficulty: Beginner | Time: 25 minutes

In this lab, you will learn how to use Nmap for network scanning and Metasploit for vulnerability analysis. You'll cover basic and advanced Nmap techniques, import scan results into Metasploit, and utilize Metasploit modules to identify and exploit vulnerabilities.

Practice on LabEx → | Tutorial →

Exploit Unreal IRCd Vulnerability with Nmap and Metasploit

Difficulty: Beginner | Time: 20 minutes

In this lab, you will learn how to exploit the Unreal IRCd vulnerability using Nmap for vulnerability scanning and Metasploit for exploitation. You'll understand the vulnerability, scan for it, exploit it, and validate the successful exploitation. This hands-on lab provides practical experience in network security.

Practice on LabEx → | Tutorial →

Network Analysis with Wireshark

Difficulty: Beginner | Time: 28 minutes

In this lab, you will learn how to perform network analysis using Wireshark. You'll install Wireshark, capture network traffic, analyze packet data, and use filters to identify and investigate network issues. This hands-on experience will enhance your cybersecurity skills.

Practice on LabEx → | Tutorial →

Explore and Customize Wireshark Interface

Difficulty: Beginner | Time: 15 minutes

In this lab, you will launch Wireshark and explore its interface. You'll learn how to navigate the various panels and customize the layout to suit your needs. This includes adjusting columns, filters, and display options for efficient network analysis.

Practice on LabEx → | Tutorial →

Network analysis is a superpower in the cybersecurity world, and these labs are your fast track to gaining it. Whether you are troubleshooting a connection or hunting for intruders, these practical skills will serve you for years to come. Don't just read about it—jump into the playground and start capturing packets today!

Master Java Core: 5 Hands-On Labs for OOP, Threading, and Encryption

Labby — Fri, 05 Jun 2026 17:34:34 +0000

Embarking on your Java journey can feel like staring at a mountain of syntax and abstract concepts. But what if you could master the language by building, breaking, and fixing real code? This curated learning path takes you from the basics of object-oriented design to the thrill of implementing your own encryption algorithms, all within an interactive environment designed for rapid skill acquisition.

Arranging Classes by Functionality

Difficulty: Beginner | Time: 5 minutes

In this lab, you will learn to use packages to arrange for classes according to their functionalities.

Practice on LabEx → | Tutorial →

Overloading and Overriding

Difficulty: Beginner | Time: 10 minutes

In this lab, you will learn method overloading and method overriding. Overriding and overloading are two concepts used in Java programming language. Both the concepts allow programmer to provide different implementations for methods under the same name. Overloading happens at compile-time while overriding happens at runtime. Static methods can be overloaded but cannot be overridden. Overloading is a static bond while overriding is dynamic bond.

Practice on LabEx → | Tutorial →

Implement Countdown Timer Thread

Difficulty: Beginner | Time: 5 minutes

In this challenge, we will be implementing a countdown timer. The objective is to create a child thread, handle time calculations using the Thread.sleep() method, and display the countdown effect based on the input number of seconds.

Practice on LabEx → | Tutorial →

Class and Object

Difficulty: Beginner | Time: 5 minutes

In this lab, you are going to learn a very important programming pattern: the object-oriented-programming. You need to know the difference between class and object. Take more practice to get a better understanding.

Practice on LabEx → | Tutorial →

Implement Encryption and Decryption

Difficulty: Beginner | Time: 5 minutes

In this challenge, we will be implementing encryption and decryption operations based on a set of encryption rules. The encryption rules involve moving the ASCII code of each character in the plaintext forward by a certain length, reversing the result characters, and then moving the ASCII code backward by another length. Our task is to design a program that can perform these encryption and decryption operations based on the given rules. We have a code template provided, and we need to complete the code in the designated areas to meet the requirements of the challenge.

Practice on LabEx → | Tutorial →

Java is more than just syntax; it is a way of structuring logic to solve complex problems. By completing these five labs, you have moved beyond simple 'Hello World' examples and into the realm of functional application development. Don't just read about code—start building it today and see how quickly your confidence grows.