reinar

database migrations will take a while for big instance, but other than that - smooth sailing.

communities

it's a band-aid, popular instances will be still under pressure to serve end users. Ok, they got the message through push from some other server instead of their user submitting it directly and the instance is not responsible for pushes to community subscribers (which is something, but not much, actually), however in the end it ends up stored locally and users still will be sending requests to popular instance to get their content if they are registered there.

users

not happening. It's a problem to change even username (and requires federation consensus first implementation-wise, it's not only lemmy around here), changing user's server will need fairly complex extension for id redirects or update propagation or something.
https://socialhub.activitypub.rocks/t/changeable-usernames/830
In general it's the same problem with migrating communities - you need to somehow update all the existing subscriptions across the federation.
I hope to be corrected on this, but this doesn't look too good.

I'm not shitting on lemmy and activitypub in general, it's a step in the right direction, however there are a lot of by-design issues which makes them prone to the very same problems as non-federated websites.

Lemmy is not truly distributed at this point, there are few well-known instances which are bearing the load and the rest is just sipping stuff through activitypub subscriptions.
If this thing will become even remotely popular with current architecture they have to follow the same path donations -> commercial or die. Serving a lot of users costs money, serving media content costs even more money. It's not a problem at the moment, but it will be.

ActivityPub is not a magic bullet, it's just a spec on how servers talk to each other. To truly involve each and every server in sharing the workload there's a need in something on top of that, or even better - replacing that since w/o active participation of client apps in load balancing it'll be the same reverse proxy shit in the end.

you need to set up port forwarding not only with your vpn provider, but also with gluetun:

https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/vpn-port-forwarding.md

good way to accidentally lose the data.

in case of any forensics your drive will be copied first and master will be not touched, any decryption attempts will be executed on copies - so kill switch is effectively useless.

there's a lot of different C's out there - I mean coding for microcontrollers looks really different to coding graphics with opengl, for example, especially for a beginner.
What do you want to do achieve with C specifically?

ramnode or linode will do, you'll need 2+GB of RAM.

C#

eh... those are fundamentally different, C is not object-oriented so OOD part goes straight out of the window. The only thing similar about them is syntax to some degree (which is really irrelevant), approach is completely different.

1000 daily visitors

it's not much, any non-micro vps from decent provider will do. For precise recommendations it'd be better to know where most of your users are located, latency is a bitch.

I've updated to 0.18.0 as well and can see your comment

It's not even about gui.
If you want to self host you get yourself a pile of software of community-level quality (i.e "it works good until it doesn't" is the best outcome) you need to care about. This means constantly being involved - updating, maintaining, learning something, etc, and honestly it's time-consuming even for experienced sysadmins.

Generated wireguard config with nat-pmp enabled in ProtonVPN panel, put keys and endpoints to my vpn client (gluetun docker image), used https://github.com/soxfor/qbittorrent-natmap image to interactively update port from qbittorrent settings on proton through natpmpc.

https://github.com/soxfor/qbittorrent-natmap/issues/13 - I've set up my docker-compose pretty much by this example (ignore "unreliability" feedback, OP probably has some issues upstream - image itself is working). If you are using this, remove all upnp/nat-pmp checkboxes from qbittorrent, this image is your nat-pmp client.

Speaking of clients: this setup is for sure extremely ugly, but native implementation of nat-pmp in libtorrent for some reason is not doing what's needed, maybe because qbittorrent tries to use upnp/nat-pmp simultaneously. What I see is an error message from upnp client ("no router found" - understandable) and complete silence from nat-pmp.