Setting Up Caddy on Linux: The Web Server That Tries to Do Your Job for You

A simple and humorous guide to installing Caddy on Linux, serving a basic HTML page, using a Caddyfile, and letting automatic HTTPS do its quiet magic.

So, you want to set up a web server.

Excellent.

That means you are ready to enter the ancient world of:

configuration files,
ports,
logs,
permissions,
and mysterious errors that appear only when you are tired.

But today we are not choosing pain as our primary operating model.

Today we are using Caddy.

Caddy is a modern web server that can serve static files, work as a reverse proxy, and handle HTTPS automatically when you use a real domain.

In other words, it does many of the boring things for you.

Not all of them, of course.
This is still Linux.
You are not completely free.

But you are much closer.

Why Caddy?

Caddy is popular because it makes common web server tasks surprisingly simple.

With Caddy, you can:

serve a simple static website,
reverse proxy an application,
use clean and readable configuration,
get automatic HTTPS with real domains,
reload configuration without turning your evening into a documentary.

If Nginx sometimes feels like reading legal paperwork written by a very serious robot, Caddy feels more like:

“Tell me what site you want, and I’ll try not to make this weird.”

Very refreshing.

Installing Caddy on Linux

Let’s install Caddy on Arch Linux, Fedora, and Ubuntu.

Choose your distribution and follow the commands.

No spiritual ceremony required.

Probably.

Arch Linux: The Courageous Route

On Arch Linux, installation is beautifully simple.

Run:

sudo pacman -Syu caddy

That’s it.

Arch users love when things are simple, because it gives them more time to explain why they use Arch.

Check that Caddy is installed:

caddy version

If you see a version number, Caddy is ready.

Your terminal has approved this operation.

For now.

Fedora: Clean, Modern, and Slightly Serious

On Fedora, install Caddy with:

sudo dnf install caddy

Then check the version:

caddy version

Fedora usually feels polished and professional, like a workstation that drinks espresso and reads documentation before breakfast.

Caddy fits nicely here.

Ubuntu: A Few More Steps, Because Tradition

On Ubuntu, we add the official Caddy repository first.

Install the required packages:

sudo apt update
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl

Add the Caddy GPG key:

curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg

Add the Caddy repository:

curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list

Make the key and repository list readable:

sudo chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
sudo chmod o+r /etc/apt/sources.list.d/caddy-stable.list

Update package lists and install Caddy:

sudo apt update
sudo apt install caddy

Now check the version:

caddy version

If it responds, congratulations.

Ubuntu and Caddy are now speaking to each other.

This is already more communication than some production systems have.

Create a Simple Website

Before we configure anything serious, let’s create a tiny HTML page.

Nothing dramatic.

Just enough to prove that the server is alive and not silently judging us.

Create a folder:

mkdir my_website
cd my_website

Create an index.html file:

nano index.html

Add this HTML:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Hello from Caddy</title>
</head>
<body>
  <h1>Hello, World!</h1>
  <p>This simple website is running through Caddy.</p>
</body>
</html>

Save the file.

You now have a website.

A small one, yes.

But even Rome started with one suspiciously placed stone.

Test Caddy Without a Caddyfile

Now let’s serve this folder directly.

Make sure you are inside the my_website folder:

pwd

Then run:

caddy file-server --listen :8080

Open your browser and go to:

http://localhost:8080

If you see your page, Caddy is working.

This is the beautiful moment where the browser shows something and you briefly feel like a system administrator.

Enjoy it.

It may not last forever.

Create a Caddyfile

Running Caddy from the command line is useful for testing.

But for a real setup, you usually want a Caddyfile.

The Caddyfile is Caddy’s configuration file.

It tells Caddy what to serve, where to serve it from, and how dramatic the evening is going to become.

Inside your my_website folder, create a file called Caddyfile:

nano Caddyfile

Add this:

localhost:8080 {
  root * .
  file_server
}

This tells Caddy:

listen on localhost:8080,
use the current folder as the website root,
serve files from that folder.

Now run Caddy using the Caddyfile:

caddy run

Open:

http://localhost:8080

If your page appears again, everything is working.

Caddy has read your instructions and behaved like a responsible adult.

Rare, but beautiful.

Format the Caddyfile

Caddy can format its own configuration file.

This is useful because computers are often better at formatting than humans who are trying to configure servers after dinner.

Run:

caddy fmt --overwrite Caddyfile

This will clean up the formatting.

A tidy Caddyfile is a happy Caddyfile.

Or at least a less suspicious one.

Validate the Configuration

Before using a configuration seriously, validate it:

caddy validate --config Caddyfile

If Caddy says the configuration is valid, good.

If it complains, read the error carefully.

Caddy errors are usually more polite than many other web server errors.

That does not mean they are always pleasant.

But at least they try.

Using a Real Domain with HTTPS

Here is where Caddy becomes very interesting.

If you have a real domain pointing to your server, you can write something like this:

example.com {
  root * /var/www/example.com
  file_server
}

With a real domain, Caddy can automatically handle HTTPS certificates for you.

That means no manual certificate wrestling.

No long ritual with random files.

No emotional battle with certificate renewal at 01:13 in the morning.

Just a clean configuration and automatic HTTPS.

Almost suspiciously nice.

A More Realistic Static Site Setup

For a real server, you probably do not want your website inside a random folder in your home directory.

A common place for websites is /var/www.

Create a folder for your site:

sudo mkdir -p /var/www/example.com

Copy your HTML file there:

sudo cp index.html /var/www/example.com/index.html

Now edit the system Caddyfile:

sudo nano /etc/caddy/Caddyfile

Use this configuration:

example.com {
  root * /var/www/example.com
  file_server
}

Replace example.com with your real domain.

Then reload Caddy:

sudo systemctl reload caddy

If reload does not work for some reason, restart it:

sudo systemctl restart caddy

Reload is gentler.

Restart is the “turn it off and on again” method.

Both have their place in the sacred history of IT.

Running Caddy as a System Service

If you installed Caddy from your distribution’s package manager, you can run it with systemd.

Enable Caddy so it starts automatically on boot:

sudo systemctl enable caddy

Start it now:

sudo systemctl start caddy

Or do both at once:

sudo systemctl enable --now caddy

Check the status:

sudo systemctl status caddy

If you see:

active (running)

Caddy is alive and working.

Your server now has a tiny employee that never sleeps.

Please treat it better than most companies treat interns.

Reloading Caddy After Changes

When you change /etc/caddy/Caddyfile, reload Caddy:

sudo systemctl reload caddy

This applies the new configuration without fully stopping the service.

Before reloading, you can also validate the system Caddyfile:

sudo caddy validate --config /etc/caddy/Caddyfile

This is a good habit.

Not an exciting habit.

But many good habits are boring.

That is why they save us from future suffering.

Checking Caddy Logs

If something does not work, check the logs:

sudo journalctl -u caddy -f

This follows Caddy’s logs in real time.

It is like listening to your server whisper:

“Here is exactly why I refuse to cooperate.”

Sometimes the logs are helpful.

Sometimes they are educational.

Sometimes they are a personal attack written in technical language.

Still, read them.

Common Caddy Commands

Here are some useful commands.

Check Caddy version

caddy version

Run Caddy in the current folder

caddy file-server --listen :8080

Run Caddy with a Caddyfile

caddy run

Format a Caddyfile

caddy fmt --overwrite Caddyfile

Validate a Caddyfile

caddy validate --config Caddyfile

Restart the system service

sudo systemctl restart caddy

Reload the system service

sudo systemctl reload caddy

View logs

sudo journalctl -u caddy -f

A Small Note About Ports

For local testing, port 8080 is comfortable.

It usually does not need special permissions and does not fight with other web servers.

For real websites, you normally use:

port 80 for HTTP,
port 443 for HTTPS.

If another service is already using those ports, Caddy may refuse to start.

To check what is listening, run:

sudo ss -tulpn

Then look for :80 or :443.

If you find another web server there, congratulations.

You now have a small server argument to resolve.

Final Thoughts

That’s it.

You installed Caddy, created a simple HTML page, served it locally, wrote a Caddyfile, and learned how to run Caddy as a system service.

Not bad.

Caddy is one of those tools that makes server setup feel less like ancient magic and more like a conversation with a very practical assistant.

It will not build your website for you.

It will not fix your CSS.

It will not explain why your JavaScript works only after refreshing the page twice.

But it can serve your site, handle HTTPS, and stay running quietly in the background.

And honestly, that is already a lot.

Enjoy your new web server.

And remember:

The best server configuration is the one you can still understand three months later.