terribleplan

Traefik. It has a GUI that I can use to see things, and (depending on your setup) you define the routes and stuff as part of your container definitions, minimal extra work required, makes setup and teardown a breeze. It is also nice that you can use it in all sorts of places, I have used it as Kubernetes ingress and as the thing that routed traffic to a Nomad cluster.

I went from Apache to Nginx (manually configured, including ACME) to Traefik over the course of the past ~10 years. I tried Caddy when I was making the switch to Traefik and found it very annoying to use, too much magic in the wrong places. I have never actually used NPM, as it doesn't seem useful for what I want...

Anyway, with traefik you can write your services in docker compose like this, and traefik will just pick them up and do the right thing:

version: "3"
services:
  foo-example-com:
    image: nginx:1.24-alpine
    volumes: ['./html:/usr/share/nginx/html:ro']
    labels:
      'traefik.http.routers.foo-example-com.rule': Host(`foo.example.com`)
    restart: unless-stopped
    networks:
      - traefik
networks:
  traefik:
    name: traefik-expose-network
    external: true

It will just work most of the time, though sometimes you'll have to specify 'traefik.http.services.foo-example-com.loadbalancer.server.port': whatever or other labels according to the traefik docs if you want specific behaviors or middleware or whatever.

And your deployment of traefik would look something like this:

version: '3'
services:
  traefik:
    image: traefik:v2
    command: >-
      --accesslog=true
      --api=true
      --api.dashboard=true
      --api.debug=true
      --certificatesresolvers.le.acme.dnschallenge.provider=provider
      --certificatesresolvers.le.acme.storage=acme.json
      [ ... other ACME stuff ... ]
      --entrypoints.http.address=:80
      --entrypoints.http.http.redirections.entrypoint.to=https
      --entrypoints.http.http.redirections.entrypoint.scheme=https
      --entrypoints.https.address=:443
      --entrypoints.https.http.tls.certresolver=le
      --entrypoints.https.http.tls.domains[0].main=example.com
      --entrypoints.https.http.tls.domains[0].sans=*.example.com
      --entrypoints.https.http.tls=true
      --global.checknewversion=false
      --global.sendanonymoususage=false
      --hub=false
      --log.level=DEBUG
      --pilot.dashboard=false
      --providers.docker=true
    environment:
      [ ... stuff for your ACME provider ... ]
    ports:
      # this assumes you just want to do simple port forwarding or something
      - 80:80
      - 443:443
      # - 8080:8080 uncomment if you want to hit port 8080 of this machine for the traefik gui
    working_dir: /data
    volumes:
      - ./persist:/data
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      - traefik
    restart: unless-stopped
networks:
  traefik:
    name: traefik-expose-network
    external: true

Note that you'd have to create the traefik-expose-network manually for this to work, as that is how traefik will talk to your different services. You can get even fancier and set it up to expose your sites by default and auto-detect what to call them based on container name and stuff, but that is beyond the scope of a comment like this.

Technically my setup is a little more complex to allow for services on many different machines (so I don't use the built-in docker provider), and to route everything from the internet using frp using proxy protocol so I don't expose my home IP... I think this illustrates the point well regardless.

Asklemmy isn't really a place to ask about lemmy, it's for asking general questions to users of lemmy, jut like you wouldn't ask for Reddit support in /r/askreddit.

Regardless, this question gets asked and talked about in the !selfhosted@lemmy.world community fairly often, here is a (slightly edited) comment I made a while back.

You will need a domain name, you can buy one from a registrar such as hover or namecheap (for the love of all that you consider holy do not use godaddy).

You will need a way to expose the server that you set up via port forwarding or similar on your network.

You will need to set up DNS records on the domain you buy to point to your home IP. You may want to figure out a different way to avoid just handing that information out, cloudflare can help with that. You will want to make sure the DNS records get automatically updated if your IP address changes, which is not uncommon for residential ISPs.

You will need to figure out how to get an SSL certificate, Let’s Encrypt will issue them for free, cloudflare gives you one if you use them as a reverse proxy.

Some of this would likely be easier to do on a cloud provider like digitalocean or linode and could be done reasonably cheaply.

These are all common things for setting up any website, so lemmy docs won't cover them. In addition to those (this answer was just addressing "how to get a URL") you will need to install and configure lemmy, lemmy-ui, postgres, and pictrs somewhere (the join-lemmy docs cover this well).

If you want your instance to send emails you will have to figure out how you want to do that (too many options to cover in this answer).

When 0.18.1 gets released if you want captcha you'll probably have to figure out an mCaptcha provider or set that up yourself.

Not to mention thinking about backups, high availability, etc, etc.

As far as hardware to host on you could get away with like ~$10/mo on most any cloud provider, run it on a Mini-PC in your closet, etc. My instance uses 1-2 GB of RAM, ~13GB of disk (and growing), and ~30% of a CPU (an old i5).

Best of luck.

Yeah, I think how most Lemmy clients (including the default web UI) handle display name is a real mistake.

1. Up to you, I would just avoid big instances like .world or .ml. People do congregate on big instances in most of the fediverse, so IDK that "professional" enters into it. It's not as if you're running a law firm on a @hotmail email address. I like hosting stuff for myself, so I am running my own instance.
2. For yourself you could get away with spending around $5-$10/mo, plus ~$10/yr for the domain name. More users/load would need more resources, .world is spending >$150/mo for the server(s) alone, and that will only grow as the instance grows.
3. Big thing would be site-wide moderation and managing federation. Dealing with reports, illegal content, communities that break server rules, users that are harassing others, etc. If you slack too much on that (or have overly lax policies) you may end up defederated by instances. Making the decision to defederate other instances. Etc.
4. Entirely gone.
5. Mostly just changes what you'd see on local. Federation can be wonky/slow at times, but that is true of federation between big instances as well, it's just something you have to get used to when using Lemmy.

Same reason people like Immersive Engineering, I assume. I've never really liked either.

"Initial sync" isn't a thing. Things only federate from communities after you subscribe to it. Old posts will make their way over if someone interacts with it (comments/votes on it). I think old comments may make their way over under the same conditions. Old votes will not make their way over so your vote count on old posts will never be right.

You can search for a post or comment to force your instance to load it (copy the federation link, the rainbow-web-looking icon) just like you would do for communities. I think there are scripts out there that may automate this process to force your instance to load old content, but you're putting more load on an already strained system.

And yes, lemmy.world is probably overloaded. Usually this just means that federation from it isn't instant and may take a little time.

I actually just migrated things to a setup that is pretty neat using FRP: I run frps on 2 Linodes in the same datacenter and have set up IP sharing for failover between them (which is a neat feature Linode, Vultr and probably a few others offer), and then I run 4 frpc's, two for each frps in case one of them breaks somehow. Lots of redundancy without all that much effort.

Pictrs is a mix of both cache and long-lived images on anything you post, your profile image, etc. So you may want to back it up... Apparently there may also be some sort of internal database pictrs uses as well, but I haven't looked into that...

I would suggest taking postgres dumps and backing those up rather than trying to back up the data directory, as according to the pg docs when taking a disk-level backup "[t]he database server must be shut down in order to get a usable backup."

It is worth noting (assuming we are referring to the same incident) the Mastodon data wasn't the target of the search, the person just happened to be actively working with a database backup when the FBI executed the warrant and took all of the person's computers and stuff.

To answer what I think you are getting at lemmy scales based on two things:

1. Database size (and write volume) scales mostly on what communities are being federated to you. Unless you are .world the volume of remote content is going to massively outweigh local content. On my (mostly) single-user instance I have found this to be the same with Pictrs as well, as it is mostly eating storage to store federated thumbnails.
2. Database read load scales mostly on the number of users you have. For a single-user instance this is pretty minimal. For an instance like .world (with thousands of users) I imagine it is significant and for such an instance you would look at scaling postgres to have read-only replicas to handle the load.

~18 hours ago I wrote

My instance has been running for 23 days, and I am pretty much the only active local user:

7.3G    pictrs
5.3G    postgres

I may have a slight Reddit Lemmy problem

As of right now

7.5G    pictrs
5.7G    postgres

So my storage is currently growing at around 1G per day, though pictrs is mostly cached thumbnails so that should mostly level out at some point as the cache expires.

To answer your stated question: I run a single user instance on a mini PC with 32G of RAM (using <2G including all lemmy things such as pg, pictrs, etc and any OS overhead) and a quad core i5-6500T (CPU load usually around 0.3). 32474 posts, 210065 comments. I don't have good numbers for bandwidth, but my frp setup in general is using ~1Mb/s average or so for everything including Lemmy.

You could probably easily run Lemmy on a Pi so long as you use an external drive for storage.

There are many ways to update dns automatically, I have used this container in the past. You could probably even write a bash script/cron job that checks your IP and updates it with curl depending on your DNS provider.

If you are already running tailscale you may be interested in using a funnel, which lets you accept and route internet traffic to your tailnet. I don't use tailscale so can't comment on how good/bad/useful this is.

You could also run some sort of service like frp from some remote box (like a VPS in DO/Linode/etc). This or the funnel lets you not expose/advertise your home IP address if that is a consideration.

I'm talking purely from an ActivityPub/Activity Streams/Activity Vocabulary/JSON-LD perspective. There are some other local identifiers for things in Lemmy, but those do not matter for the purposes of federation. Any Object that is federated is expected to have an ID that is a URL at which you can make a GET request with the proper Accept header and you will get the latest version of that Object. AFAIK there is no provision for IDs to change.