Self-Hosting with Docker Guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

A compose file is a small host you can rebuild

Self-hosting here means one service on a machine you administer, described by a compose file. The generator drafts that file. It does not talk to the engine. The Docker guide owns the first image. This page owns the file that runs a lab you intend to keep for a while.

The homelab companion on the system desk is the neighbouring story for the room, the hardware, and the spare machine. This page does not pick a hypervisor. It assumes a host that already runs the engine, and it keeps the service off the public internet until a ticket says otherwise.

A volume is the data. The container is replaceable. Write the volume name and how you would copy it before you need to. A second container is not a backup. A snapshot you have never restored is a hope.

Updates are one image tag at a time. You do not bump every image in the file on a Friday because a notice said they were old. The tag you pin is the tag you can return to.

One service, localhost, a volume with a name

Pick one lab service you can explain, such as a notes tool with invented content. Draft the compose file. Read the image tag, the ports, and the volumes. Bind published ports to 127.0.0.1. A publish to every interface is a line you change.

Name the volume after the service and the environment. Do not mount a directory that already holds something you cannot replace, and do not mount the engine socket. Privileged mode stays out unless a sentence in the ticket would still make sense next month.

Write the update habit: which tag, who changes it, and the previous tag you will keep. Write the backup habit in one sentence, even if the job is a later calendar entry. The cost note matters if this host is a cloud machine that bills while you sleep.

Secrets stay in a file the repository does not contain, or in the secret store. prompt-for-this in the draft is the reminder. A password in the compose file is a password you rotate if it was ever real.

# Compose lab. One service.
# Bind ports to 127.0.0.1.
# Name the volume. Do not mount the engine socket.
# Pin the tag you can roll back to.
# prompt-for-this is not a password.
# Invent the content. No customer extract.

A change you can finish

Starting the stack is a lab hour on the host in the ticket, after the file is reviewed.

Rollback is the previous tag and the volume you did not delete. Deleting the volume is not a reset.

Choose one service and write what it stores.
Draft the compose file and pin the tag.
Bind ports to localhost.
Name the volume and the backup sentence.
Remove secrets, privileged mode, and the engine socket.
Keep the previous tag written down.
Leave extra services for later files.

Mistakes that outlive the command

self-hosting with Docker fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.

Every port published on every interface.
The engine socket mounted into a container.
A password in the compose file.
An unpinned tag.
A customer extract as the first content.
Deleting the volume to fix a start error.
Updating every image at once.
A second service added because the file had room.
No backup sentence.
A cloud host with no stop or owner, billing quietly.
Calling a second container a backup.
Treating this page as the hardware guide.

Decisions to write down before the window

One decision for self-hosting with Docker: One service is named. The host is one you administer. Ports bind to localhost. The tag is pinned. The volume name is obvious. A backup sentence exists. No secret is in the file. Privileged mode is absent. The socket is not mounted. The content is invented. The previous tag is written. And extra services wait.

The hour you stop

Write the account, the project or subscription, the region, and the clock time before you change anything for self-hosting with Docker. If this account is serving people and you do not have a way back, this hour is a plan. A plan you can read tomorrow is a success. A change you cannot undo is not.

Use a lab account, a lab project, or a lab subscription you administer. You do not point a CLI, a pipeline, or a browser tool at an account you do not run. The tools on this site run in the browser. They draft text. They do not log in, and they do not scan.

prompt-for-this is a reminder that a secret is missing. It is not an access key, a token, a password, or a kubeconfig you save. The real secret stays in the password store or the platform's secret store. If a file, a log, a ticket, or a pipeline still contains a live secret, stop and rotate it. Then delete the copy.

One change. A network, a virtual machine, a policy, and a pipeline do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous file, the previous plan, or the resource you can delete because it was only a lab.

A second person reads the scope aloud: which account, which region, which name. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.

Documentation addresses stay in the note. 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, and 2001:db8::/32 are not prefixes you type into a production network. example.com is not your zone. A generated file that opens 0.0.0.0/0 is a file you edit before it is applied. A source you can name is the rule you keep.

Do not apply a draft you have not read. A cost estimate, a policy, a manifest, and a Terraform plan are reading material. Apply, a resize of a live machine, and a delete of a bucket are later decisions with their own proof. Read the names. Then decide.

Keep the previous file. A generator draft is not the previous file. The previous file is what you put back if the new one is wrong. You practised the path back, including the serial console or a second admin, before you changed a network or a lockout setting.

If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied stack produces an account nobody can explain. Rebuild the lab from the copy you kept.

When the checks pass, the next account waits until someone else can repeat the proof from the notes. self-hosting with Docker is done for this window when the proof is written, not when a CLI printed a success line.

This page is a planning guide. It is not a vendor manual, not an official standard, not legal advice, and not an audit opinion. If an auditor must see the decision, they see the ticket and the evidence, not this paragraph.

Hand the finished note to the neighbouring guide that owns the next step, and leave this account alone until that guide has its own window.

Self-hosting checks before the stack starts

Confirm this before you call the change done: The compose file is in the ticket. The host name matches. Ports are on localhost. The tag is pinned. The volume is named. A backup sentence exists. No password is in the file. The socket is not mounted. The content plan uses invented data. A second service is absent. The cost or power owner is named if the host bills or stays on. A second person read the published ports. The hostname in the prompt matches the hostname in the ticket for self-hosting with Docker. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for self-hosting with Docker happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Docker Compose Generator

Guides in this cluster

These supporting pages belong to this pillar.

Companion: System: Homelab Guide for Sysadmins.