- caddy_v2 - reverse proxy
- bitwarden_rs - password manager
- bookstack - notes and documentation
- borg_backup - backup utility
- ddclient - automatic DNS update
- dnsmasq - DNS and DHCP server
- homer - homepage
- nextcloud - file share & sync
- portainer - docker management
- prometheus_grafana - monitoring
- watchtower - automatic docker images update
- arch_linux_host_install
The core of the setup is Caddy reverse proxy.
It's described in most details.
You do need to have basic docker and docker-compose knowledge, shit here is pretty hand holding and detailed, but it still should not be your first time running a docker container.
When making changes to Caddyfile, the config needs to be reloaded afterwards.
On the docker host:
docker exec -w /etc/caddy caddy caddy reload
Assuming container name is kept as caddy.
When making changes use docker-compose down and docker-compose up -d,
not just restart or stop/start.
- you do not need to fuck with
docker-compose.ymlto get something up, simple copy paste should suffice - you do need to fuck with
.envfile, that's where all the variables are
Often the .env file is used as env_file
env_file: .env
.env- actual name of a file that is used only by compose.
It is used automatically just by being in the directory with thedocker-compose.yml
Variables in it are available during the building of the container, but unless named in theenvironment:option, they are not available in the running containers.env_file- an option in compose that defines an existing external file.
Variables in this file will be available in the running container, but not during building of the container.
So a setup having env_file: .env in the compose mixes these two together.
Benefit is that you do not need to make changes at multiple places,
adding variable or changing a name in .env does not require
to also go in to compose to add/change it there...
Also the compose file looks less cramped.
Only issue is that all variables from the .env file are available in
all containers that use this env_file: .env method.
That can lead to potential issues if a container picks up enviroment
variable that is intented for a different container of the stack.
In the setups here it works and is tested, but if you start to use this
everywhere without understanding it, you can encounter issues.
So first troubleshooting step should be abandoning .env and write out
the variables directly in the compose file under containers that want them.
All images are without any tag, which defaults to latest tag being used.
This is frowned upon,
but feel free to choose a version and sticking with it once it goes to real use.
No docker volumes are used. Directories and files from the host
are bind mounted in to containers.
Don't feel like I know all of the aspects of this,
but I know it's easier to edit a random file on a host,
or backup a directory when it's just there, sitting on the host.
For sending emails free sendgrid account is used, which provides 100 free emails a day.
The configuration in .env files is almost universal, apikey is
really the username, not some placeholder.
Only the password(actual value of apikey) changes,
which you generate in apikey section on SendGrid website.
Though I heard complains lately that is not as easy as it was to register on SendGrid.
For managing DNS records. The free tier provides lot of managment options and benefits. Like proxy between your domain/subdomain and your server, so no one can get your public IP just from your domain name. Or 5 firewall rules that allow you to geoblock whole world except your country.