This English version was written and translated by Hermes Agent.

Three-line summary

When running multiple services on a home server, a Docker and Docker Compose based setup is much easier to manage than installing everything directly.
If each service has its own directory and keeps docker-compose.yml, .env, and data volumes in one place, it becomes much easier to troubleshoot later.
Rather than exposing many services to the outside from the beginning, it is important to bring them up one by one on the internal network and confirm that the data persists.

Running Self-hosted Services on a Home Server with Docker

In the previous post, I covered preparing a mini PC, installing Ubuntu Server, and getting it into a state where I could connect through SSH.

At that point, the home server is basically a “machine I can access like a server.”
But it still does not have any services that I can actually use.

The reason I built a home server was not simply to keep one Linux server running.
It was to run the services I need myself, store my data on my side, and add automation when needed.

In this post, I want to summarize the process of installing Docker and Docker Compose on Ubuntu Server,
organizing a per-service folder structure, and bringing up my first self-hosted services one by one.

Why I decided to run services with Docker

There are many ways to run services on a home server.

Install executable files directly
Install them through a package manager
Split things into virtual machines
Manage everything with a Kubernetes cluster

But I decided to run my services with Docker.
The reason was simple.

When there is only one service, installing it directly can be fine.
But once the number grows to two, three, or ten, it becomes difficult.

Each service may require a different version.
Additional dependencies such as a DB or Redis may be needed.
The locations of configuration files and stored data are all different.

-> If I install all of that directly on the server, it becomes hard to manage later.

I also considered Kubernetes, but I have not yet decided how much knowledge or direction I want there, so I thought it was YAGNI for now.

With Docker and Docker Compose, I can leave the way a service runs in a single file.

The information needed to run a service is usually something like this.

Which image to use
Which ports to open
Which environment variables to use
Where to store data
Whether to restart the container when it dies
Whether it depends on services like a DB or Redis

Docker Compose lets me keep this configuration in a docker-compose.yml file.

In other words, while running a home server, the important thing was not simply “running services,” but
“leaving them in a form that I can understand again later.”
(So I can move them to another mini PC or reuse them whenever I need to.)

So I started with this basic execution environment for the home server.

Ubuntu Server
+ Docker
+ Docker Compose
+ Per-service directories
+ docker-compose.yml
+ .env
+ Explicit volume paths

At the very least, I wanted a structure where I could tell where each service lives and how it runs.

Services

I will skip the basic installation and usage of Docker and Docker Compose.

The first thing I thought about was the folder structure.
At first, it is possible to create a docker-compose.yml anywhere and run it.

But once services increase, it quickly becomes confusing.

Where is this service's Compose file?
Where is the data stored?
Where is the .env file?
Which directory should I go to if I want to see the logs?

When things reach that state, running the home server becomes tiring.

So I decided to keep Docker-related files in one place.

/home/yeongsu/docker/
├── homepage/
├── uptime-kuma/
├── memos/
├── filebrowser/
├── html-share/
├── immich/
├── ryot/
└── windmill/

The basic rules were:

One service = one directory
Configuration files = stored inside the service directory
Data volumes = managed explicitly

docker-compose.yml and data management

When I first used Docker Compose, I thought of it simply as a configuration file for running containers.
But I started to feel that docker-compose.yml is both an executable file and a kind of document.

For example, by looking at a Compose file, I can understand things like:

Which image this service uses
Which ports it uses
What data is stored where
Which environment variables are required
Whether there is a restart policy
Whether it depends on containers like a DB or Redis

The important part here is volumes.

Containers can be deleted and recreated. But data must not disappear.
So it is better to connect service data to host directories explicitly whenever possible.

volumes:
  - ./data:/data

With this setup, even if I recreate the container, the data stored in the ./data directory remains.

Also, while operating services, environment variables are often needed.

Admin accounts
DB connection information
External API settings
and so on

I separated those values into .env files.

The structure looks roughly like this.

service-name/
├── docker-compose.yml
├── .env
└── data/

Services I brought up

There are so many self-hosted services if you start looking for them.

awesome-selfhosted Repo

Among them, I will briefly introduce the services I actually brought up.

There are quite a few, so it should be fine to pick only the ones that look interesting from the titles.

관련 포스트

ON THIS PAGE

관련 포스트

ON THIS PAGE