Now Put Linux to Work — Build Your Own Web Server on a Raspberry Pi
Learning Linux commands is useful.
But there comes a point when simply moving files around, listing directories and installing packages stops feeling like a project.
So now that we have discovered Linux, it is time to make Linux actually do something.
One of my favourite first projects is surprisingly ambitious:
Build your own web server and host a website from your own Raspberry Pi.
You can start with a blank Raspberry Pi, type a handful of commands into the terminal and, a short while later, open a browser on another computer and see a web page being delivered by the Pi.
Then comes the really interesting possibility.
With some additional configuration, that little computer sitting on your desk can serve a website to somebody hundreds or thousands of miles away.
At that point Linux suddenly stops being an operating system you are studying.
It becomes part of the Internet.
What Exactly Is a Web Server?
When you visit a website, your browser is not normally downloading pages from some mysterious thing called "the Internet".
It is communicating with another computer.
Your browser sends a request.
The remote computer receives that request and sends something back — perhaps an HTML page, an image, some JavaScript or data.
The program performing that job is the web server.
Popular web-server packages include Apache and Nginx.
For this project I am going to use Apache, partly because it is extremely well established and partly because it makes a very approachable first Linux server project.
Raspberry Pi OS is based on Debian Linux, which means software can be installed using Debian's package-management system. The current Raspberry Pi OS is based on Debian, making standard Linux server tools readily available.
Why a Raspberry Pi Is Such a Good Server Project
A Raspberry Pi is not going to replace the enormous server infrastructure used by Amazon, Google or Microsoft.
That isn't the point.
For a small personal website, school project, development server, experimental dashboard or home intranet, it is remarkably capable.
More importantly, it allows students to see several areas of computing come together at once.
Suddenly we are dealing with:
Linux commands and file systems;
HTML and CSS;
IP addresses;
client-server computing;
TCP/IP networking;
ports;
DNS;
permissions;
services and processes;
cybersecurity;
remote access.
That is why I like this project so much.
We are no longer learning these ideas as isolated examination topics.
We are building something in which they all have a purpose.
Step 1 — Start With Your Raspberry Pi
You need relatively little equipment:
A Raspberry Pi running Raspberry Pi OS, a microSD card or SSD, a network connection and access to a terminal.
You can use the full Raspberry Pi OS desktop or Raspberry Pi OS Lite.
For a dedicated server, Lite is particularly interesting because it has no graphical desktop. You are interacting with the machine almost entirely through the command line.
That initially feels like a disadvantage.
It quickly becomes part of the attraction.
You begin to realise that a server doesn't actually need a screen, keyboard or mouse permanently attached to it.
It just needs to be running.
Step 2 — Update Linux
Open the terminal and begin with:
sudo apt update
sudo apt upgrade -y
There are several useful Linux ideas contained in those two commands.
sudo means we are running the command with elevated administrator privileges.
apt is the package-management system.
update downloads current information about available packages.
upgrade updates software already installed on the machine.
This is a good habit before installing new server software.
It is also an opportunity to discuss something that is sometimes missed when students study operating systems:
software maintenance is part of running a computer system.
A server that works perfectly but is never updated eventually becomes a security problem.
Step 3 — Install Apache
Now comes the wonderfully satisfying part.
Type:
sudo apt install apache2 -y
That is essentially it.
Linux downloads Apache, installs the necessary files and configures the web-server software.
You can check it with:
systemctl status apache2
You should see that Apache is running.
The systemctl command gives us another useful Linux concept.
Apache isn't simply a program we have opened in a window.
It is running as a service.
The server can start automatically when the Raspberry Pi starts and continue running quietly in the background.
That is how much of Linux server administration works.
Step 4 — Find the Raspberry Pi's Address
Every device on your home network needs an IP address.
Try:
hostname -I
You might see something resembling:
192.168.1.74
The exact address will be different on different networks.
Now go to another computer, tablet or phone connected to the same network and enter:
http://192.168.1.74
using your own Pi's address.
If everything has worked, something rather wonderful happens.
A web page appears.
It isn't coming from Google.
It isn't coming from a web-hosting company.
It is coming from the Raspberry Pi sitting beside you.
The Raspberry Pi Foundation has long used essentially this kind of Apache experiment as an introduction to hosting local HTML pages on a Pi.
Pause Here — Because Something Important Has Happened
This is a moment worth thinking about.
We installed some software.
The software opened a service listening for web requests.
Another machine found the Raspberry Pi using its IP address.
A browser sent an HTTP request across the network.
Apache received it.
Apache located an HTML document.
Apache sent the document back.
The browser interpreted the HTML and displayed the result.
We have just constructed a genuine client-server system.
Suddenly those network diagrams found in computing textbooks make considerably more sense.
Step 5 — Replace the Default Page With Your Own Website
The standard Apache website files are normally stored in:
/var/www/html
Go there:
cd /var/www/html
Have a look:
ls
You should find an HTML file.
We can replace it with our own page.
For example:
sudo nano index.html
Then create something simple:
<!DOCTYPE html>
<html>
<head>
<title>My Raspberry Pi Server</title>
</head>
<body>
<h1>Hello from my Raspberry Pi!</h1>
<p>This webpage is being served by a computer in my house.</p>
<p>I built this server using Linux and Apache.</p>
</body>
</html>
Save the file.
Refresh the browser.
Your page appears.
There is something particularly satisfying about this because we can immediately see the result of what we have done.
Now Make It Look Like a Proper Website
The next stage is obvious.
Add some CSS.
Create several pages.
Add photographs.
Build navigation.
Perhaps create:
index.html
about.html
projects.html
contact.html
You could create folders for:
/images
/css
/javascript
Now our Linux project has naturally become a web-development project as well.
A student who has learned some HTML and CSS can suddenly host what they have created on a real server rather than simply double-clicking an HTML file on their computer.
That difference matters.
Try Talking to the Server Without a Browser
There is another lovely Linux experiment we can perform.
On the Raspberry Pi type:
curl http://localhost
Instead of beautifully formatted text and pictures, you should see the HTML returned directly to the terminal.
Why?
Because curl is acting as the client.
The browser isn't essential.
This is an excellent demonstration of the difference between the data returned by the server and the way a browser interprets that data.
Look Behind the Scenes
Once a student has a working server, there is plenty more to investigate.
For example:
sudo systemctl restart apache2
restarts the server.
You can look at Apache's log files:
cd /var/log/apache2
and examine requests arriving at the server.
One particularly interesting command is:
sudo tail -f /var/log/apache2/access.log
Leave that running and visit your website from another device.
Requests begin appearing.
Refresh the browser.
Another request appears.
Visit another page.
Another appears.
This is the Internet becoming visible.
A website visit that seems almost instantaneous from the user's side is actually producing identifiable network activity on the server.
A Great Networking Investigation
There is an excellent experiment you can perform before going anywhere near the public Internet.
Try accessing the Raspberry Pi from:
the Raspberry Pi itself;
another computer connected by Ethernet;
a laptop connected by Wi-Fi;
a phone connected to your home Wi-Fi;
the same phone after switching Wi-Fi off.
The first four may work.
The fifth probably will not.
Why?
Because something fundamental has changed.
The phone is no longer part of your local network.
And that introduces one of the most important distinctions in networking:
a private IP address is not the same as a publicly reachable Internet address.
So How Do We Put the Website on the Internet?
This is where the project becomes even more interesting.
Inside your house, your Raspberry Pi might have an address such as:
192.168.1.74
That is a private address.
Millions of networks can use addresses like that.
Someone elsewhere on the Internet cannot simply type that address and arrive at your Raspberry Pi.
Traditionally, we solve this using technologies including:
NAT, port forwarding, DNS and a public IP address.
A home router can be configured so that requests arriving on particular ports are forwarded to your Raspberry Pi.
Web traffic commonly uses:
Port 80 = HTTP
Port 443 = HTTPS
You might also register a domain name so that people visit something meaningful such as:
www.myexperimentalsite.co.uk
rather than remembering an IP address.
Suddenly DNS — another subject that can seem rather abstract when taught from a diagram — has a very obvious purpose.
But Don't Simply Open Everything on Your Router
This is also where the project gives us an important lesson in cybersecurity.
Putting a server onto the public Internet means computers anywhere in the world can attempt to communicate with it.
That means we need to think about security before simply opening ports.
At a minimum, a public server should be kept updated, unnecessary services should remain closed, administrator accounts should use strong authentication, remote SSH access should preferably use keys rather than passwords, and a public website should use HTTPS.
Raspberry Pi's own current security guidance recommends key-based authentication for improving SSH security and also discusses tools such as Fail2Ban for systems operating as servers.
This is another reason this project is so valuable.
Cybersecurity stops being a theoretical discussion about "hackers".
The student now owns a machine that may potentially be reachable from the Internet.
The question becomes:
What exactly am I exposing?
A Modern Alternative — Use a Secure Tunnel
There is another approach that I think is particularly interesting for an educational project.
Instead of opening incoming ports on your home router, services such as Cloudflare Tunnel can create an outbound connection from the Raspberry Pi to a public service.
Your website can then be associated with a public hostname without directly exposing your home's public IP address or opening inbound ports.
Cloudflare describes its Tunnel system as using an outbound-only connection, allowing a public hostname to be mapped to a local service such as a web server running on localhost.
That gives us another excellent computing discussion.
There are now at least two possible architectures:
Internet
|
Router
|
Port forwarding
|
Raspberry Pi
or:
Internet
|
Tunnel provider
|
Encrypted outbound tunnel
|
Raspberry Pi
Neither should simply be memorised.
Ask instead:
What are the advantages, disadvantages and security implications of each?
That is much closer to real computing.
What About HTTPS?
When browsing modern websites you will normally see:
https://
rather than:
http://
The S matters.
HTTPS encrypts the communication between the browser and web server and uses certificates to establish the site's identity.
This provides another natural extension to the project.
Instead of merely asking students to define encryption or digital certificates, let them investigate what has to happen to turn their own HTTP website into an HTTPS website.
Tools such as Certbot can obtain certificates and configure supported web servers, with automated renewal available on typical installations.
Now suddenly public-key cryptography, certificates and certificate authorities have a reason to exist.
A Website Is Only the Beginning
Once the basic server works, there are dozens of directions in which this project could develop.
You could create a personal portfolio.
You could host revision material.
You could build a household information page.
You could display data from a Raspberry Pi sensor.
You could connect a weather station.
You could create a database-backed application.
You could write a Python application and put a web interface in front of it.
You could make a dashboard displaying temperature, pressure, humidity or electricity generation.
You could create a small API that another computer queries.
You could even have several Raspberry Pis sending measurements back to one central server.
The simple HTML page has become the starting point for much more substantial computing projects.
My Favourite Extension — Build a Live Science Dashboard
For somebody interested in both computing and science, this is where things become especially interesting.
Imagine connecting a temperature sensor to the Raspberry Pi.
A Python program records:
Time
Temperature
Humidity
Pressure
The readings are saved.
The web server then displays them.
Now somebody on another computer can open a browser and see the latest measurement.
Add a graph and the project becomes better still.
You now have:
Sensor -> Raspberry Pi -> Python -> Data -> Web server -> Network -> Browser
That is a complete system.
Each individual element is understandable, but together they form something genuinely useful.
Turn It Into a Proper Student Investigation
Rather than providing every instruction, I would be tempted to give students a challenge:
Can you build a website on a Raspberry Pi that I can view from another computer without anybody telling you exactly how to do it?
Once they succeed, introduce the next challenge:
Can you work out how the second computer actually found the Raspberry Pi?
Then:
Can somebody outside our network see it?
Then:
Why not?
Then:
How could we make that possible safely?
That sequence transforms the exercise from following instructions into problem solving.
And that is where some of the best computing education happens.
Useful Questions to Ask Along the Way
A project like this can generate considerably more learning if students have to explain what is happening.
What does sudo actually do?
Why do we need apt update?
What is a Linux service?
Why does Apache continue running after we close the terminal?
Where are the website files stored?
Why can another computer access the Raspberry Pi?
What does an IP address identify?
Why does localhost work?
What is port 80?
What is the difference between a private and public IP address?
What does DNS do?
Why is HTTPS preferable to HTTP?
Why might directly exposing a home computer to the Internet be risky?
Those questions move the exercise far beyond simply copying commands.
From Command Line to Internet Server
This is exactly why I think students should experience Linux rather than merely learn definitions about it.
At the beginning we type:
sudo apt install apache2
It looks like just another Linux command.
But follow what happens next.
Software is downloaded.
A service starts.
A network port begins listening.
A second computer sends a request.
Linux receives it.
Apache processes it.
A file is retrieved from the filesystem.
It is transmitted across the network.
A browser interprets it.
A website appears.
Then perhaps we introduce DNS.
Then HTTPS.
Then server logs.
Then scripting.
Then databases.
Then security.
One small Raspberry Pi has become a laboratory for understanding an enormous proportion of modern computing.
Conclusion — Don't Just Learn Linux. Build Something With It.
There is a danger when teaching computing that operating systems, networks, programming and cybersecurity become separate chapters.
Students learn a definition of an IP address.
Then they learn some Linux commands.
Then perhaps some HTML.
Then they learn that port 80 is used for HTTP.
Then they memorise what DNS does.
A web-server project pulls those separate ideas back together.
The IP address now has a purpose because we need to find our Raspberry Pi.
HTML has a purpose because we need something for Apache to serve.
Ports matter because requests must reach the correct service.
DNS matters because people prefer names to numbers.
Linux permissions matter because server files must be controlled.
HTTPS matters because communication across a public network should be protected.
Cybersecurity matters because putting a computer on the Internet has consequences.
And perhaps most importantly, the student finishes with something that actually works.
There is a considerable difference between being told how a web server works and typing an address into a browser on another computer and seeing a page that is being delivered by a Raspberry Pi sitting on your own desk.
That is when Linux starts to feel less like another topic in Computer Science.
It starts to feel like a tool.
And once students realise that, there is an enormous amount they can build next.


