I have and continue to build this exact thing but with kubernetes as a base.

If you have enough docker container that you feel youd like to use docker swarm, you can use already kubernetes.

- either gitlab or github (now both have free private repos) - Ubuntu with microk8s - argocd for sync between git and your k8s - argocd to manage your application - argocd has a declartive setup, you can configure argocd through argocd! https://argoproj.github.io/argo-cd/operator-manual/declarati... - your application with a simple docker container + a litte bit of yaml - traefik + lets encrypt -> dns out of the box / with little effort

Now you can use your host to store your data and backup only that folder where you have all your storage needs, or you go with longhorn or openebs. With that setup you have all of your setup as code in your git (automatically backedup) and all configs in your storage system or storage path.

If you then would like to have a ltitle bit of high availability, take a raspi, install ubuntu with microk8s and join your single node cluster.

You can then either use tekton inside your already existing cluster to have your own small build pipeline for your images or you connect gitlab.com with your private k8s cluster so that you have your own gitlab runner. Which you don't need as gitlab is allowing free builds.

prometheus operator (promethus + grafana) is already available as an addon in microk8s. Its just one line to enable it -> monitoring done.

You can continue with this by buying yourself a small server, install microk8s on that, join it to your cluster and now you can deploy automagically to the internet.

What is the reason for requiring a cloudflare account?

> For this setup you'll need...

> Cloudflare Account

That defeats the point of self hosting in my opinion. If traffic is flowing through cloudflare then I'm no longer in charge of some key bits of metadata.

Hey, repo poster here. The requirements are if one wishes to be able to follow all the directions completely. Depending on your drivers you may or may not want Cloudflare. Some advantages of Cloudflare are privacy (hiding your actual server IP (if you proxy all the addresses,)) caching (if you expect a lot of traffic,) nice API control of name server functions, and it's free. But, you trade that for unencrypted man in the middle, certainly an understandable deal-breaker for certain situations. Cloudflare can be skipped and your domain mapped directly to your edge server IP using your registrar dns panel.

Good to know and that part should be clarified in the readme so that upon skimming it's clear that cloudflare is optional.

Good idea. Done.

How does the caddy instances on the home network side get certificates for accessing directly from the LAN?

Currently all access goes out to the net and returns via the edge node. Works, but we can improve this. The ability to go LAN to LAN is an advantage of home hosting and some (many of the newer) web api services require https to work. One possible approach, on todo, adds a name server service on the LAN which maps your domains locally when you're LAN side, and a mechanism added which forwards certs generated on the edge node Caddy instance to be used on the LAN Caddy instance.