Self host your own code repo. Forgejo is adding activitypub and federation features, not sure how far long they are, but someday if enough people start self-hosting we might have a viable decentralized way to collaborate on and contribute to each others’ projects.

If it’s strictly for personal use, Nextcloud can do this easily (no upload required since the client handles the sync), although it’s a very heavyweight way to do it and for security reasons most people probably have Nextcloud set up behind a VPN-wall like Tailscale or something so it may not work for you.

However, it technically has a share link feature that does exactly this. If you’re using the desktop or mobile client you just have to put it in one of Nextcloud’s sync folders and then right click on it or whatever to get a share link to the file. You can also do it through the web UI (both the upload itself and getting the link to it) You can make the share link public and permanent so anyone who can access the Nextcloud server can get access to that file through the link.

Worth considering if you already have a Nextcloud instance. Alternately, if you aren’t already using Nextcloud for sensitive personal files, and just want a repository of silly meme images you can share freely, giving public access to it (it’s still locked behind an account for upload and general access) isn’t that much of a security concern and then your public links should work just fine.

If you want something that is more of a social media site and image gallery like Imgur is, maybe Immich can handle some of that, but if your goal is simply sharing image file links, I’d focus on looking for things that are more for sharing files, since images are just files and it doesn’t sound like you need all the complex image-specific handling really.

Agree, I don’t blame the people becoming cynical and distrustful, I think that’s a totally rational and valid response to the current situation. I blame the people (government representatives and companies, more to the point) who are making this the situation in the first place.

I don’t want to live in a world where we trust no-one and nothing. But it’s delusional not to see that we do live in a world that is rapidly moving that direction. We need to do something (a lot of things) to stop it, but we also can’t pretend it’s not happening.

No, you are definitely not the only one. I tend to be more judgemental of projects that contain prolific use of emojis in general, but that has been ongoing since before AI became popular.

Running it as a VM or even on a server that is running other services and potentially competing for I/O or memory bandwidth also introduces many other potential sources of inefficiency. I always recommend running a firewall on dedicated bare metal hardware, it is a very specialized task with very particular requirements on behalf of both the hardware and the software and it has very little tolerance for other sources of latency or delays. That doesn’t mean you need to use a pre-built appliance, but it does explain why it’s so common, and running it on a VM on a server that is doing other stuff is likely contributing to your issues significantly.

Personally, I run my firewall/router on a very stripped-down Debian with almost no non-essential services and a custom built kernel. I hand-picked a multi-port PCIe x4 Intel NIC with good Linux compatibility and drivers, and I’m using foomuuri to handle the routing and kea to handle DHCP/DNS for my internal network. This is a very minimal, bare-bones configuration and I wouldn’t really recommend it unless you really know what you’re doing, and it’s absolutely not “idiot mode networking” and if that’s what you want you’re going to have a real bad time if you try to follow in my footsteps, because I am a very different kind of idiot. But it works for me, so it’s proof that it is possible.

The purpose of the health check is to allow docker itself to talk to whatever service is running on the container to make sure it’s always responding happily, connected to everything it needs to be connected to for proper operation, and is not overloaded or stuck somehow.

Docker does this by pretending to be a web browser, and going to the specified “health check URL”. The key thing I think you’re missing here is that the health check URL is supposed to be a URL that, ideally, runs on your container and does some meaningful checks on the health of your service, or at the very least, proves that when you connect to it, it is able to serve up a working static page or login page or something (which doesn’t actually prove it’s working completely, but is often good enough)

Now, you’re probably wondering why this isn’t automatic, and the answer is because there’s no standard “health check URL” that fits all services. Not all services even respond to URLs at all, and the ones that do may have different URLs for their health checks, they may need different hostnames to be used, etc.

By setting health check URL to example.com, basically what you’re doing is constantly testing whether the real-world website https://example.com/ way over there somewhere is working, and as long as it is, docker assumes your container is fine. Which it might be, or it might not be, it has no idea and you have no idea, because it’s not even attempting to connect to the container at all, it’s going to the URL you specified, which is way out there on the internet somewhere, and this effectively does nothing useful for you.

It’s understandable why you probably thought this made sense, that it was testing network connectivity or something, but that is not the purpose of the health check URL, and if you don’t have a meaningful URL to check, you can probably just omit or disable the healthcheck in this case. Docker only uses it to decide if it needs to restart the container or alert you of the failure.

Aha I see you did the text-based install then? I’ve never done that myself but I just tried it now and it worked fine for me with the default password it mentions. Make sure caps lock is off. You will not be able to see the password when you type it, so be extra careful you are typing it correctly.

Most of the same cautions about internet access still apply, if your networking is active on this VM there’s a non-zero chance you can get hacked right away when you’re in default passwords/initial setup mode. If you continue to have trouble getting in, you should reinstall it once again onto a fresh VM with network mode set to NAT if possible, or even disabled completely, and see if it works in that configuration. It really is critical to get the password set up before opening up the internet.

Not sure what you mean by “what was provided”… who is providing a username and password for your yunohost?

You are supposed to create your own username and password during the “Begin” setup process after it first installs. “root” and “yunohost” are very insecure and if you use passwords that are copy/pasted from somewhere else on a machine connected to the internet it will be hacked, potentially almost immediately. People have bots that literally just try to connect using these common default passwords all day every day to every site on the internet. I have literally had machines with such crappy passwords hacked within minutes of spinning them up. The same thing can happen even when you are first doing the setup process. If somebody else can get in, they can (most likely with a bot) do the setup process themselves and set up their OWN username/password, and now it will ask you for that password that THEY set, which you have no way of knowing. The instance belongs to the first person to claim it, and if that’s not you, you have to wipe it and start over.

Your yunohost VM interface should not be exposed to the internet during setup. Even briefly, or someone else can immediately compromise it like this. The only way to ensure you are the first person to access it is to make sure you are the ONLY person who can access it, until it is properly set up and secured. Bots are WAY faster than you can be.

Use localhost console, VM port forwarding or some other secure method of making sure nobody but your own host computer can access the IP of the server where you are setting things up, until it has a strong, secure password (not “yunohost”) and make sure you have all its security features configured and working before you even think about making it accessible to the internet.