yunohost VS Caddy

Pull that old laptop from the closet, the one with the broken screen and keyboard which made you so sad to put it to pasture since it did have plenty of memory and CPU to keep up. Install Debian on the thing followed by Proxmox Virtual Environment (PVE) [1]. Since you have 16GB of RAM in that laptop (or 8 but 16 is nicer) you should be able to run a number of containers [2].

Here's an idea, more or less based on a number of servers I configured for friends and family, based on 8GB Raspberry Pi 4 hardware with 2/4TB USB SSD. Your laptop will offer better performance.

- Create 4 or 5 containers and name them 'auth', 'serve´, 'base', 'backup' and 'mail' (if you want to run your own mail that is, otherwise skip that one). Their functions are:

> auth runs LDAP, Kerberos (if you want that), a central letsencrypt instance which takes care of all your certificate needs and anything else related to authentication and authorisation

> base runs databases, that means Postgresql, Mysql/Mariadb, Redis, RabbitMQ and whatnot - all depending on what you need.

> serve runs services, that means nginx or another web server which is used as a reverse proxy for the other web-related things you want to run: 'cloud' services like Nextcloud with everything that comes with it (e.g. Collaboraoffice or Onlyoffice to replace whatever web-based office things you currently use), communications services like XMPP, application-specific proxies like Invidious/Nitter/Libreddit, media services like Peertube/Airsonic/Ampache, a Wiki like Bookstack, search services like SearxNG, etc. - the size of your server is the limit.

> backup runs Proxmox Backup Server and is used to backup everything to some external drive and to some outside repository.

> mail runs mail services, only if you want to run those. I always say 'do it' but many people have an irrational fear of running their own mail services. That fear is not grounded in truth, running mail is not hard and offers many advantages over hosted solutions.

While it is possible to separate all the mentioned services out into their own containers I think this adds needless complexity for little to no gain. Separating out database services makes sense since those can end up quite taxing and as such might well be moved to their own hardware in some (possibly not too distant) future. Separating out authentication services makes sense since that lowers the attack surface compared to running them together with externally available services. The same goes for mail services which is why I put those in their own container.

Once you've got this up and running you can create a few more containers to play around with. If you just want to try out services something like Yunohost [3] or Caprover [4] can come in handy but I do not see these as viable alternatives to installing and running services which you intend to keep around for a long time.

Of course you can do most of this on a VPS as well but I prefer to keep thing in-house - the fewer dependencies, the better.

[1] https://proxmox.com/en/

[2] containers perform better and take less memory than VMs but if VMs are your thing that is possible as well

[3] https://yunohost.org

[4] https://caprover.com/

Yunohost is one of those mature projects, that's fully open source.

YunoHost, although not Docker-based, is still nice and quite mature.

If you want something like that, then CasaOS is pretty great and i can recommend it, especially for a beginner. There is also Cosmos and Tipi. Yunuhost too but a bit different approach. Oh and Umbrel is a thing...

However you quickly reach the limits of what Umbrel can do, its very basic in its abilities. Of course it depends all on what you (or anyone else) wants to do with it. There is also CasaOS which is very similar to Umbrel but last i compared, Casa offered a bit more features like for example adding your own docker projects easily. There is also Tipi which i must admit i havent taken a closer look at yet. And there is Yunohost which i guess aims at a similar audience but achieves these things differently, still worth mentioning tho.

This looks exciting and definitely something to look out for as an option fkr self-hosting.

Similiar and a little bit more mature is also YunoHost, https://yunohost.org/, or for professional environments, UCS https://www.univention.com/.

I use https://yunohost.org on my Pi, mostly for monitoring other stuff but you can get Nextcloud running just fine with it!

No, look at the associated unit test: https://github.com/caddyserver/caddy/blob/c6eb186064091c79f4...

If that test fails we could serve PHP source code instead of having it be evaluated, a major security flaw.

However, it's very unlikely that .NET developers will directly expose their Kestrel-based web apps to the internet. Typically, we use other popular web servers like Nginx, Traefik, and Caddy to act as a reverse-proxy in front of Kestrel for various reasons:

I think that recompiling with upgraded Go will not solve the issue. It seems Caddy imports `golang.org/x/net/http2` and pins it to v0.22.0 which is vulnerable: https://github.com/caddyserver/caddy/issues/6219#issuecommen....

Caddy [1] is a single binary. It is not minimal, but the size difference is barely noticeable.

serve also comes to mind. If you have node installed, `npx serve .` does exactly that.

There are a few go projects that fit your description, none of them very popular, probably because they end up being a 20-line wrapper around http frameworks just like this one.

[1] https://caddyserver.com/

Each app’s front end is built with Qwik and uses Tailwind for styling. The server-side is powered by Qwik City (Qwik’s official meta-framework) and runs on Node.js hosted on a shared Linode VPS. The apps also use PM2 for process management and Caddy as a reverse proxy and SSL provisioner. The data is stored in a PostgreSQL database that also runs on a shared Linode VPS. The apps interact with the database using Drizzle, an Object-Relational Mapper (ORM) for JavaScript. The entire infrastructure for both apps is managed with Terraform using the Terraform Linode provider, which was new to me, but made provisioning and destroying infrastructure really fast and easy (once I learned how it all worked).

So I dug a little deeper and came across this gem: Caddy. Caddy is this fantastic, extensible, cross-platform, open-source web server that's written in Go. The best part? It comes with automatic HTTPS. It basically condenses all the work our scripts and manual maintenance were doing into just 4-5 lines of config. So, stick around and I'll walk you through how to set up an automatic SSL solution with Caddy, Docker and a Node.js server.

Let's use Caddy which can act as reverse-proxy with automatic HTTPS coverage.

Even if it may be simple, it doesn't handle edge cases such as https://github.com/caddyserver/caddy/issues/1632

I personally would make the trade off of taking on more complexity so that I can have extra compatibility.

One of the most heavily used Russian software projects on the internet https://www.nginx.com/blog/do-svidaniya-igor-thank-you-for-n... but it's only marginally more modern than Apache httpd.

In light of recently announced nginx memory-safety vulnerabilities I'd suggest migrating to Caddy https://caddyserver.com/