Build Your First Node.js Web Server

Build and debug a local Node.js server with home, health, and 404 routes.

Introduction

30 Second Summary

When you visit a website, you expect each address to give you the right answer. A useful page confirms what works while a missing one explains what went wrong.

In this project, you will build the first local service for an evolving Intern Hub with Node.js. You will watch an HTTP server turn each incoming URL into a distinct response.

What You'll Build

You'll run the Intern Hub inside Visual Studio Code and watch each local address return the response you designed.

By the end of this project, you'll have:

  • A working home route that displays Intern Hub is online in the integrated browser.
  • A JSON health check that returns {"status":"ok"}. An unsupported address returns Not found with HTTP status 404.
  • A local Git repository you can inspect to see how version control recognizes your project files.
  • Secret Mission: Add a lightweight request log that prints each HTTP method and URL in the terminal.

Are there any prerequisites?

You need permission to install approved software on your computer. No coding knowledge or online service account is required.

Before We Start

Before any hands-on work, this is your moment to commit to a local Intern Hub service that turns incoming URLs into distinct HTTP responses. That request-response foundation prepares you to add React or AWS later.

Set Up Your Developer Toolkit

The Intern Hub needs a consistent local toolchain before you write its server code. A shared toolchain removes machine-specific friction from every later check.

Visual Studio Code keeps your editor beside your terminal. This gives you one place to create the server and watch it run.

Node.js runs JavaScript locally. Git tracks changes inside a repository.

In this step, get ready to:
  • Install Visual Studio Code Stable.
  • Install Node.js 24.20.0 LTS.
  • Install Git and verify the complete toolkit.
Install Visual Studio Code

Visual Studio Code provides the workspace for this project. Its integrated terminal lets you run development commands beside your code.

  • Select the tab that matches the current state of Visual Studio Code on your computer.

✔️ Visual Studio Code opens

macOS

  • Press Cmd+Space to open Spotlight.
  • Type Visual Studio Code into Spotlight.
  • Press Enter to open Visual Studio Code.

You should see the Visual Studio Code editor window.

Windows

  • Press the Windows key to open search.
  • Type Visual Studio Code into search.
  • Press Enter to open Visual Studio Code.

You should see the Visual Studio Code editor window.

Linux

  • Open your desktop application launcher.
  • Search for Visual Studio Code.
  • Select Visual Studio Code from the search results.

You should see the Visual Studio Code editor window.

ⓧ It is not installed yet

Install the Stable release using the instructions for your operating system.

macOS

  • Visit the official Visual Studio Code macOS setup page.
  • Download the Stable macOS release.
  • Open the downloaded .dmg file.
  • Drag Visual Studio Code.app to Applications.
  • Press Cmd+Space to open Spotlight.
  • Type Visual Studio Code into Spotlight.
  • Press Enter to open Visual Studio Code.

You should see the Visual Studio Code editor window.

Windows

  • Visit the official Visual Studio Code Windows setup page.
  • Download the Stable User Setup installer.
  • Open the downloaded installer.
  • Complete the installation prompts.
  • Press the Windows key to open search.
  • Type Visual Studio Code into search.
  • Press Enter to open Visual Studio Code.

You should see the Visual Studio Code editor window.

Linux

Linux distributions use different package formats. Choose the official package that matches your distribution.

  • Visit the official Visual Studio Code Linux setup page.
  • Select the official Debian, RPM, or Snap package for your distribution.
  • Install the selected package with your distribution's package manager.
  • Open your desktop application launcher.
  • Search for Visual Studio Code.
  • Select Visual Studio Code from the search results.

You should see the Visual Studio Code editor window.

Good work. Visual Studio Code is open and ready to hold the complete local workflow.

Visual Studio Code does not open?

  • Confirm that you completed the installer for your operating system.
  • On macOS, confirm that Visual Studio Code.app is inside Applications.
  • On Linux, confirm that the package matches your distribution.

Help me install Visual Studio Code on my computer.

Install Node.js 24.20.0 LTS

Node.js is the runtime that executes your server code. The project uses the exact LTS release v24.20.0 so every learner runs the same JavaScript environment.

  • Select Terminal from the Visual Studio Code top menu.
  • Select New Terminal.

You should see an integrated terminal panel at the bottom of Visual Studio Code.

  • Check the active Node.js version by running this command:
node --version

What does this command check?

The command asks Node.js to print the version available on your PATH. This confirms which runtime your terminal uses.

✔️ I see v24.20.0

That exact output confirms Node.js is installed correctly. Your integrated terminal can now run JavaScript with the project runtime.

ⓧ I see another version

Your terminal found Node.js, but it found a different release. Install v24.20.0 so the workshop uses one consistent runtime.

macOS

Windows

  • Visit the official Node.js 24.20.0 release page.
  • Download node-v24.20.0-x64.msi for an x64 computer.
  • Download node-v24.20.0-arm64.msi for an ARM64 computer.
  • Open the installer that matches your computer.
  • Complete the installation prompts.

Linux

Matching a Linux archive to the device can feel fiddly. Your device architecture determines which official archive you need.

  • Visit the official Node.js 24.20.0 release page.
  • Download node-v24.20.0-linux-x64.tar.xz for an x64 computer.
  • Download node-v24.20.0-linux-arm64.tar.xz for an ARM64 computer.
  • Extract the selected archive to an approved software location.
  • Ask your IT team to place the archive's bin directory on PATH if your device is managed.
  • Close every Visual Studio Code window.
  • Return to Visual Studio Code using your operating system search.
  • Select Terminal from the top menu.
  • Select New Terminal.
  • Verify the replacement Node.js version by running this command:
node --version

What does this command confirm?

The reopened terminal reads the updated PATH. The version output confirms whether the new runtime is active.

You should now see v24.20.0.

ⓧ Command not found

Your terminal cannot find Node.js yet. Install the official v24.20.0 LTS release for your operating system.

macOS

Windows

  • Visit the official Node.js 24.20.0 release page.
  • Download node-v24.20.0-x64.msi for an x64 computer.
  • Download node-v24.20.0-arm64.msi for an ARM64 computer.
  • Open the installer that matches your computer.
  • Complete the installation prompts.

Linux

Matching a Linux archive to the device can feel fiddly. Your device architecture determines which official archive you need.

  • Visit the official Node.js 24.20.0 release page.
  • Download node-v24.20.0-linux-x64.tar.xz for an x64 computer.
  • Download node-v24.20.0-linux-arm64.tar.xz for an ARM64 computer.
  • Extract the selected archive to an approved software location.
  • Ask your IT team to place the archive's bin directory on PATH if your device is managed.
  • Close every Visual Studio Code window.
  • Return to Visual Studio Code using your operating system search.
  • Select Terminal from the top menu.
  • Select New Terminal.
  • Verify the Node.js installation by running this command:
node --version

What does this command confirm?

The reopened terminal reads the updated PATH. The output confirms whether Node.js is available to local projects.

You should now see v24.20.0.

Still missing Node.js?

  • Close every Visual Studio Code window after completing the Node.js installer.
  • Return to Visual Studio Code using your operating system search.
  • Create a fresh integrated terminal from the Terminal menu.
  • On managed Linux devices, ask IT to confirm that the selected archive's bin directory is on PATH.

Help me make Node.js v24.20.0 available in Visual Studio Code.

Install Git and verify the toolkit

Git records changes inside a local repository. This project only needs local Git, so you do not need a GitHub account or identity configuration.

What might macOS show?

On macOS, checking Git can open the Command Line Tools installation prompt when Git is absent.

  • Accept the Command Line Tools prompt if macOS shows it.
  • Check whether Git is available by running this command in the integrated terminal:
git --version

What does this command check?

The command asks Git to print its installed version. Any version line confirms that the terminal can use Git.

✔️ I see a Git version line

Git is installed and available from your integrated terminal. Your local version-control tool is ready.

ⓧ Command not found

Git needs to be installed before you can create the Intern Hub repository.

macOS

  • Accept the Command Line Tools installation prompt opened by the Git version check.
  • Wait until macOS confirms that the installation is complete.

Windows

  • Visit the official Git for Windows download page.
  • Download the official Git for Windows installer.
  • Open the downloaded installer.
  • Complete the installation prompts.

Linux

The installation command depends on your Linux distribution.

  • Install Git on Debian or Ubuntu by running this command:
sudo apt install git-all
What does this command do?

The Debian package manager installs Git and its supporting tools. Your system may request administrator approval.

  • Install Git on Fedora by running this command:
sudo dnf install git-all
What does this command do?

The Fedora package manager installs Git and its supporting tools. Your system may request administrator approval.

  • Close every Visual Studio Code window after Git finishes installing.
  • Return to Visual Studio Code using your operating system search.
  • Select Terminal from the top menu.
  • Select New Terminal.
  • Verify the Git installation by running this command:
git --version

What does this command confirm?

The new integrated terminal reads the updated PATH. A version line confirms that Git is ready.

You should now see a Git version line.

The final check proves that your editor can reach both command-line tools. First, confirm the Visual Studio Code installation itself.

macOS

  • Select Code from the macOS menu bar.
  • Select About Visual Studio Code.

You should see the Visual Studio Code About dialog with installation details.

Windows

  • Select Help from the Visual Studio Code top menu.
  • Select About.

You should see the Visual Studio Code About dialog with installation details.

Linux

  • Select Help from the Visual Studio Code top menu.
  • Select About.

You should see the Visual Studio Code About dialog with installation details.

  • Close the About dialog.
  • Return to the integrated terminal you opened earlier.

Before you run the final check, do you expect both tools to answer from the same Visual Studio Code terminal?

  • Run both final version checks with these commands:
node --version
git --version

What does this final check prove?

  • The first command confirms that the integrated terminal can find the required Node.js runtime.
  • The second command confirms that the same terminal can find Git.

You should see v24.20.0 followed by a Git version line. That is the hard part done. Your editor, runtime, and version-control tool now work together.

Seeing a missing command?

  • Close every Visual Studio Code window.
  • Return to Visual Studio Code using your operating system search.
  • Create a fresh integrated terminal from the Terminal menu.
  • Run the two version checks again.

Help me fix a missing toolkit command.

Your developer toolkit is ready. Next up, you'll create the local Git repository and launch the first Intern Hub response.

Launch the First Intern Hub Server

Your development toolkit is ready. Now the Intern Hub needs a local service you can actually open.

You’ll use Node.js to run your first HTTP server. A browser request will reach your JavaScript code and receive a plain-text response.

Why the Built-In HTTP Module?

The built-in HTTP module exposes each request and response directly. This keeps the request-response cycle visible while you learn how a server works.

A framework such as Express adds project setup plus automatic handling for unsupported paths. The built-in module keeps this first server small enough to inspect line by line.

In this step, get ready to:
  • Create the intern-launchpad workspace as a local Git repository.
  • Build the Intern Hub’s first server.
  • Open the home URL inside Visual Studio Code.
Create the project workspace

A Visual Studio Code workspace keeps the files for one project together. Opening the folder first also gives your terminal a clear location for the Git repository.

  • Select File in the top menu.
  • Select Open Folder....

You’ll see your computer’s folder picker.

  • Select the Desktop folder.
  • Select New Folder.

You’ll see a field where you can name the new folder.

  • Enter intern-launchpad as the folder name.
  • Select Open on macOS or Select Folder on Windows and Linux.

The Explorer sidebar now shows intern-launchpad as your workspace folder.

You created this empty folder yourself, so you can safely enable Visual Studio Code’s workspace features.

  • Select Yes, I trust the authors if the Workspace Trust dialog appears.
  • Select Terminal in the top menu.
  • Select New Terminal to create a terminal rooted at intern-launchpad.

The terminal prompt now points to the intern-launchpad folder.

  • Initialize the folder as a local repository by running this command:
git init

What Does This Command Do?

The command adds hidden repository metadata to intern-launchpad. Git can now track changes inside this folder without creating a commit.

The terminal confirms that an empty Git repository was initialized inside intern-launchpad.

Repository Initialized Somewhere Else?

Check that the terminal prompt ends with intern-launchpad. Return to the workspace terminal before trying the repository initialization again.

Ask for help if the folder shown in your terminal does not match the folder in Explorer. Help me confirm that my Visual Studio Code terminal is rooted at the intern-launchpad folder.

  • Inspect the repository’s current state by running this command:
git status

What Does This Command Do?

The command inspects the current working tree. It reports whether the repository has commits or untracked files.

Git reports a repository with no commits yet. This confirms that intern-launchpad is ready to track your server file.

Build the first server

A server listens for incoming requests at a specific address. This first version answers every request with the same home message.

  • Select the New File button in the Explorer sidebar.
  • Enter server.js as the file name.

You’ll see an empty editor tab named server.js inside the intern-launchpad workspace.

  • Add the first working server to server.js by pasting this code:
const http = require('node:http');

const hostname = '127.0.0.1';
const port = 8000;

const server = http.createServer((_request, response) => {
  response.statusCode = 200;
  response.setHeader('Content-Type', 'text/plain');
  response.end('Intern Hub is online\n');
});

server.listen(port, hostname, () => {
  console.log(`Server running at http://${hostname}:${port}/`);
});

What Does This Code Do?

  • The require('node:http') import loads Node.js’s built-in HTTP tools.
  • The hostname value limits the server to your computer.
  • The port value gives the server a numbered entry point.
  • The http.createServer callback runs whenever a request reaches the server.
  • The response.statusCode value sends the successful status code 200.
  • The response.setHeader call labels the body as plain text through a response header.
  • The response.end call sends Intern Hub is online. It also completes the response.
  • The server.listen call starts listening at the configured hostname and port.
  • Save server.js by pressing Cmd+S on macOS or Ctrl+S on Windows and Linux.

The Explorer sidebar lists server.js under intern-launchpad.

Does Your Server Code Look Different?

Check the single quotes around text values. Check the backticks around the server message inside console.log.

Compare every closing brace and parenthesis with the reference below. Help me compare my server.js file with the working Intern Hub server code.

✔️ Awesome, I've got everything!

Your first server is saved in server.js and ready to run.

ⓧ I'd like to double check the full code

const http = require('node:http');

const hostname = '127.0.0.1';
const port = 8000;

const server = http.createServer((_request, response) => {
  response.statusCode = 200;
  response.setHeader('Content-Type', 'text/plain');
  response.end('Intern Hub is online\n');
});

server.listen(port, hostname, () => {
  console.log(`Server running at http://${hostname}:${port}/`);
});
Run the server and open it

Starting the server keeps this terminal occupied while it listens for requests. The running process stays connected to the code in server.js.

Before you run this, predict the address the terminal will print.

  • Start the server by running this command:
node server.js

What Does This Command Do?

The node command executes server.js from the current folder. The process stays active because the server is listening for browser requests.

The terminal prints Server running at http://127.0.0.1:8000/. This confirms that Node.js is listening for local connections.

Server Did Not Start?

Confirm that the terminal prompt was inside intern-launchpad before you started the process. Confirm that server.js is saved in that folder.

A message mentioning the port can mean another process is already using 8000. Help me diagnose why node server.js did not start my local server.

Before you load the page, predict the response the server will return.

  • Press Cmd+Shift+P on macOS or Ctrl+Shift+P on Windows and Linux to open the Command Palette.
  • Enter Browser: Open Integrated Browser in the Command Palette.
  • Select Browser: Open Integrated Browser from the results.

You’ll see an integrated browser panel inside Visual Studio Code.

  • Enter http://127.0.0.1:8000/ in the integrated browser’s address bar.

You’ll see Intern Hub is online in the integrated browser. That is your first Intern Hub service responding to a real browser request.

Your Intern Hub home response is live. Next, you’ll test an unsupported URL to discover how this first version handles it.

Expose the Broken Routing

Your Intern Hub is live inside Visual Studio Code. The home page proves your Node.js server can answer one HTTP request.

A single successful URL leaves a gap. You do not know how the server behaves when someone requests a missing path.

This step tests that edge case. The result gives you a concrete defect to explain before you change any code.

In this step, get ready to:
  • Request an unsupported path from the integrated browser.
  • Compare the unsupported path with the home path.
  • Explain why the listener cannot distinguish between paths.
Test an unsupported path

A route maps a requested path to a specific response. Testing a path that your server does not support reveals whether that mapping exists.

Before you test it, do you think the missing path produces a different response from the home path?

  • Switch back to the Visual Studio Code integrated browser from the previous step.
  • Select the address field.
  • Enter http://127.0.0.1:8000/does-not-exist.
  • Press Enter to request the unsupported path.

You will see Intern Hub is online even though the address ends in /does-not-exist.

This incorrect result is the designed failure. Your server has treated an unsupported path like the home path.

Trace the defect in the listener

The browser result proves that the server received the request. The cause sits inside the request listener that builds every response.

  • Select server.js in the Visual Studio Code Explorer sidebar.
  • Find const server = http.createServer((_request, response) => {.
  • Scan the listener body for any use of _request.

You will find that the listener never reads _request. It always builds the same response.

Why Does Every Path Look the Same?

  • The _request parameter represents the incoming request. No line inside the listener reads it.
  • The response object always receives status 200.
  • The response always uses Content-Type set to text/plain.
  • The fixed response body prevents the requested path from changing the result.

This is an observation-only step. Your server.js file should still match the version from the previous step.

✔️ Awesome, I've got everything!

Great. Your server remains unchanged while the browser exposes its routing defect.

ⓧ I'd like to double check the full code

const http = require('node:http');

const hostname = '127.0.0.1';
const port = 8000;

const server = http.createServer((_request, response) => {
  response.statusCode = 200;
  response.setHeader('Content-Type', 'text/plain');
  response.end('Intern Hub is online\n');
});

server.listen(port, hostname, () => {
  console.log(`Server running at http://${hostname}:${port}/`);
});

What Should I Compare?

The listener still uses _request. Its body contains one fixed response.

Matching this file confirms that you reproduced the flaw without changing the server.

Before the final comparison, do you expect the two addresses to produce different text?

  • Switch back to the integrated browser.
  • Enter http://127.0.0.1:8000/ in the address field.
  • Press Enter.

You will see Intern Hub is online on the home path.

  • Enter http://127.0.0.1:8000/does-not-exist in the address field.
  • Press Enter.

You will see Intern Hub is online again. You found the gap: different URLs reach one fixed response.

You have reproduced the routing defect without changing the server. Next, you will make the listener inspect each URL and return the correct response.

Add Real Routes and Responses

Your last check proved the Intern Hub answers an unsupported URL with the home message. That visible defect gives you a precise target: the server needs to choose a response from the requested path.

Explicit routes let Node.js inspect request.url before it completes each HTTP response. You will add a home route, a health route, and a fallback that reports missing paths.

In this step, get ready to:
  • Route the home request using request.url.
  • Return a machine-readable health response.
  • Return a 404 response for every unsupported path.
Route the home request

Start by making the known home path explicit. This runnable slice preserves the home response while giving the listener access to the requested URL.

  • Switch back to server.js in the editor from earlier.
  • Replace the current request listener with the code below:
const server = http.createServer((request, response) => {
  if (request.url === '/') {
    response.statusCode = 200;
    response.setHeader('Content-Type', 'text/plain');
    response.end('Intern Hub is online\n');
    return;
  }
});

What Does This Code Do?

  • The request parameter carries information about the incoming browser request.
  • The request.url check selects the home route when the requested path is /.
  • The return statement exits the listener after the home response is complete.
  • Save server.js.
  • Stop the running server by pressing Ctrl+C in the integrated terminal.
  • Restart the updated server by running:
node server.js

Why Restart the Server?

The node command runs the saved version of server.js. A fresh process loads your new request listener.

  • Return to the integrated browser from earlier.
  • Enter http://127.0.0.1:8000/ in the address field.

The home route displays Intern Hub is online. Your first explicit route is working.

Still Seeing the Earlier Behavior?

  • Confirm that you saved server.js before restarting the server.
  • Stop the earlier process before starting the updated server again.

Help me check why my updated home route is not running.

Add the health route

A health route gives software a small machine-readable response that confirms the service is available. This route uses JSON so another application can read the result predictably.

  • Place the code below directly after the home route block inside the request listener:
  if (request.url === '/health') {
    response.statusCode = 200;
    response.setHeader('Content-Type', 'application/json');
    response.end('{"status":"ok"}\n');
    return;
  }

How Does the Health Route Work?

  • The route check selects this response when request.url equals /health.
  • The Content-Type header identifies the response body as application/json.
  • The response body reports the service status as {"status":"ok"}.
  • Save server.js.
  • Stop the running server by pressing Ctrl+C in the integrated terminal.
  • Restart the server with the new health route by running:
node server.js

What Happens on Restart?

The new process loads both route checks from the saved file. The listening message confirms that the server is ready for another browser request.

  • Enter http://127.0.0.1:8000/health in the integrated browser.

The page displays {"status":"ok"}. The Intern Hub now has a machine-readable health response.

Health Route Keeps Loading?

  • Confirm that the health block sits inside the request listener.
  • Check that the route begins with the leading slash in /health.
  • Confirm that each opening brace has a matching closing brace.

Help me debug my health route.

Return a 404 fallback

The home and health checks both exit after sending their responses. Any request that reaches the final lines therefore needs a missing-page status code.

  • Place the fallback code below the health route block inside the request listener:
  response.statusCode = 404;
  response.setHeader('Content-Type', 'text/plain');
  response.end('Not found\n');

How Does the Fallback Work?

  • The fallback runs only when neither earlier route completes the request.
  • The 404 status identifies the requested path as missing.
  • The Not found body gives the browser a clear visible result.
  • Save server.js.
  • Predict which response each of the three URLs should select after the restart.
  • Stop the running server by pressing Ctrl+C in the integrated terminal.
  • Start the completed server by running:
node server.js

What Confirms the Restart?

The terminal prints Server running at http://127.0.0.1:8000/. This confirms the updated server is listening for requests.

  • Enter http://127.0.0.1:8000/ in the integrated browser.

The home route shows Intern Hub is online.

  • Enter http://127.0.0.1:8000/health in the integrated browser.

The health route shows {"status":"ok"}.

  • Enter http://127.0.0.1:8000/does-not-exist in the integrated browser.

The unsupported route now shows Not found.

  • Open the integrated browser's Developer Tools.
  • Reload http://127.0.0.1:8000/does-not-exist.
  • Select the /does-not-exist request.

The request details show status 404. That's the routing defect fixed.

Your server now maps three URL cases to three visible HTTP outcomes.

Routes Still Returning the Same Response?

  • Confirm that both route checks appear before the fallback response.
  • Check that each successful route ends with return.
  • Restart the server after saving the completed file.

Help me debug my route order and responses.

✔️ Awesome, I've got everything!

Your saved server.js now contains all three route outcomes.

ⓧ I'd like to double check the full code

const http = require('node:http');

const hostname = '127.0.0.1';
const port = 8000;

const server = http.createServer((request, response) => {
  if (request.url === '/') {
    response.statusCode = 200;
    response.setHeader('Content-Type', 'text/plain');
    response.end('Intern Hub is online\n');
    return;
  }

  if (request.url === '/health') {
    response.statusCode = 200;
    response.setHeader('Content-Type', 'application/json');
    response.end('{"status":"ok"}\n');
    return;
  }

  response.statusCode = 404;
  response.setHeader('Content-Type', 'text/plain');
  response.end('Not found\n');
});

server.listen(port, hostname, () => {
  console.log(`Server running at http://${hostname}:${port}/`);
});

Secret mission

Add Request Logging

Your routes already return the right responses. Add one log line that reveals every request method and URL in the terminal while preserving the server's behavior.

Clean Up Your Resources

Clean Up Your Resources

Your Intern Hub runs entirely on your computer without cloud resources or ongoing charges. Decide whether to keep the server running, pause it for later, or delete the local project.

Resources you used:

  • A running Node.js server process using port 8000.
  • The intern-launchpad folder containing server.js and a local Git repository with no commits.

Keep everything running

No action needed. Choose this if you want to keep testing the Intern Hub server.

  • Leave the Node.js server process running in the integrated terminal.
  • Keep the intern-launchpad folder on your computer.
  • Continue testing the home route, health route, or request log whenever you want to experiment.

Pause - I'll come back to this later

Stopping the server frees the integrated terminal. Your project files remain ready for another session.

  • Switch back to the integrated terminal in Visual Studio Code.
  • Press Ctrl+C to stop the local server.
  • Keep the intern-launchpad folder for your next session.

Delete - I don't want to use this again

Deleting the folder is permanent. The commands below target only intern-launchpad, so your other folders stay untouched.

  • Switch back to the integrated terminal in Visual Studio Code.
  • Press Ctrl+C to stop the local server.
  • Select your operating system below.

macOS

  • Remove the local repository and confirm its deletion by running these commands:
cd ..
rm -rf intern-launchpad
ls
What do these commands do?
  • The first command moves the terminal to the folder containing intern-launchpad.
  • The removal command permanently deletes the local project folder.
  • The final command lists the folders that remain.

Your local project is fully removed. The directory listing no longer includes intern-launchpad.

Windows

  • Remove the local repository and confirm its deletion by running these commands:
cd ..
cmd /c "rmdir /s /q intern-launchpad"
dir
What do these commands do?
  • The first command moves the terminal to the folder containing intern-launchpad.
  • The removal command permanently deletes the local project folder.
  • The final command lists the folders that remain.

Your local project is fully removed. The directory listing no longer includes intern-launchpad.

Linux

  • Remove the local repository and confirm its deletion by running these commands:
cd ..
rm -rf intern-launchpad
ls
What do these commands do?
  • The first command moves the terminal to the folder containing intern-launchpad.
  • The removal command permanently deletes the local project folder.
  • The final command lists the folders that remain.

Your local project is fully removed. The directory listing no longer includes intern-launchpad.

Nice Work!

Nice Work!

You did it! Your local Node.js server now turns each URL into the correct HTTP response.

You've learned how to:

  • Verified Visual Studio Code, Node.js v24.20.0, and Git. Initialized the local intern-launchpad repository with no commits.
  • Built route-specific responses for /, /health, and unsupported URLs. Returned plain text, JSON, or status 404 based on the requested URL.
  • Reproduced the routing defect at /does-not-exist. Fixed it with explicit URL checks using request.url.
  • Secret Mission: Added request logging with request.method and request.url. Confirmed each browser request appears in the terminal.

Ready to quiz yourself?