Lemmy

An up to date step by step instruction for docker, ansible, or scratch setup would be a fantastic step in the right direction. I'm not a complete moron, but I feel the current guides are lacking. There's a lot of assumptions on the admins knowledge of the associated systems beforehand. As someone else said, the first to make a turnkey solution... hot dog. Would absolutely blast adoption into space.

Thanks for offering your knowledge! I successfully set up and instance using their docker installation guide. However I was never able to get the smtp server to work. I first tried to add postfix to the docker-compose file like they have in the ansible installation example on github, but that didn't work. Just trying to add an email address to my account would stall the UI with a spinning animation on the Save button. I then tried to update the hjson config file by adding my sendgrid api credentials and removing postfix from docker compose. That gave me the same result. At that point I kinda gave up and deleted my vps. I don't have access to my error logs anymore, but I can spin up a new vps to try to get the same errors again if needed.

I feel like there's a lot of money on the table for the first person to set up a turnkey hosting platform for Lemmy. Something like MoltenHosting but for Lemmy instead of Foundry.

Perhaps write a thread, with step-by-step text and photos/screenshots per platform? And then the next one to do would be a step-by-step video?

Example, I'm not technically minded, but have an Unraid box with a 1Gb connection. There are extra steps there that I'm aware of but have no idea how to do because it's over my head.

Something that would help a lot of selfhoster types would be prebuild docker images and a good example docker compose. (something kbin could also use)

Do you think it would be possible to host using a raspberry pi 4?

How much traffic does Lemmy create daily?

I've been playing with my own single-user instance here using Docker. Mostly I just followed the Lemmy docs. It's been nice & responsive and takes barely any resources, so far. I think this system can really benefit from a lot of small instances to spread the load.

You’re awesome

Depending on how much Lemmy get's hugged to death I might take you up on this. Thanks!

Hi there - thanks for posting. I’m serving lemmy (ansible install) on nginx from Ubuntu 22.04 and I’m seeing this weird problem sometimes where the submit button is not enabled on the “create post” form. Sometimes it works but then it inexplicably stubbornly refuses to - I am not seeing any apparent error show up in the console, nothing in the lemmy or nginx logs (naturally, because the HTML form isn’t submitting to the server because the submit button's disabled). Happens in different browsers, tried restarting nginx, rebooting, nothing seems to fix it. Now, my addled brain does recall seeing something about Ubuntu 22.04 having some issues with Lemmy and perhaps that’s what I’m seeing - it’s just weird and I’ve never seen a web app do this before - any ideas? The url is quex.cc and you’re welcome to test there if you like, but I'm really just looking for any suggestions for investigation before I start thinking about moving to a different OS.

Being a highly technical guy, I struggled to get everything running on the server that I am hosting other things on. The biggest hurdle was letsencrypt, but other things weren't working quite right. I ended up just paying for a new ubuntu vps so I can run the ansible playbook (I use arch linux everywhere else). That turned out to be super simple and "just worked".

The thing I struggled with the most was adapting the provided docker-compose.yml for my Caddy setup.

I am using caddy-docker-proxy, which I absolutely love but their documentation is not the greatest for matchers.

If anyone else wants a super basic Lemmy instance running on Caddy with their domain on Cloudflare here is a docker-compose.yml

Please make sure you update your lemmy.hjson hostname field to match the domain you used in the docker-compose.yml for the caddy labels

If you're not using Cloudflare you can replace build: . (and not use the Dockerfile I provided below) in the caddy service with image: lucaslorentz/caddy-docker-proxy:ci-alpine (and remove the caddy.acme_dns label) and I believe it will fall back to Let'sEncrypt

version: "3.9"

services:
  caddy:
    container_name: caddy
    build: .
    depends_on:
      - lemmy-ui
      - pictrs
    ports:
      - 80:80
      - 443:443
    environment:
      CADDY_INGRESS_NETWORKS: caddy
    networks:
      - caddy
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /opt/docker/caddy/data:/data
      - /opt/docker/caddy/config:/config
    labels:
      caddy.log.format: console
      caddy.acme_dns: cloudflare YOUR_CLOUDFLARE_API_TOKEN
    restart: unless-stopped
  lemmy:
    container_name: lemmy
    image: dessalines/lemmy:0.17.3
    depends_on:
      - postgres
      - pictrs
    environment:
      RUST_LOG: "warn,lemmy_server=info,lemmy_api=info,lemmy_api_common=info,lemmy_api_crud=info,lemmy_apub=info,lemmy_db_schema=info,lemmy_db_views=info,lemmy_db_views_actor=info,lemmy_db_views_moderator=info,lemmy_routes=info,lemmy_utils=info,lemmy_websocket=info"
    networks:
      - caddy
    volumes:
      - /opt/docker/lemmy/lemmy.hjson:/config/config.hjson:ro
    labels:
      caddy: "your.domain.com"
      caddy.@lemmy: path_regexp ^/(api|pictrs|feeds|nodeinfo|\.well-known)/.*$
      caddy.@post: method POST
      caddy.@accept: header Accept application/*
      caddy.reverse_proxy_1: "@lemmy {{upstreams 8536}}"
      caddy.reverse_proxy_2: "@post {{upstreams 8536}}"
      caddy.reverse_proxy_3: "@accept {{upstreams 8536}}"
    restart: unless-stopped
  lemmy-ui:
    container_name: lemmy-ui
    image: dessalines/lemmy-ui:0.17.3
    depends_on:
      - lemmy
    environment:
      LEMMY_UI_LEMMY_INTERNAL_HOST: lemmy:8536
      LEMMY_UI_LEMMY_EXTERNAL_HOST: localhost:1234
      LEMMY_HTTPS: true
    networks:
      - caddy
    labels:
      caddy: "your.domain.com"
      caddy.reverse_proxy: "{{upstreams 1234}}"
    restart: unless-stopped
  pictrs:
    container_name: pictrs
    image: asonix/pictrs:0.3.1
    environment:
      PICTRS__API_KEY: API_KEY
    user: 991:991
    volumes:
      - /opt/docker/pictrs:/mnt
    networks:
      - caddy
  postgres:
    container_name: postgres
    image: postgres:15-alpine
    environment:
      POSTGRES_DB: lemmy
      POSTGRES_USER: lemmy
      POSTGRES_PASSWORD: password
    volumes:
      - /opt/docker/postgres:/var/lib/postgresql/data
    networks:
      - caddy
    restart: unless-stopped

networks:
  caddy:
    external: true

Here is the Dockerfile used for the caddy container:

ARG CADDY_VERSION=2.6.4

FROM caddy:${CADDY_VERSION}-builder AS builder

RUN xcaddy build \
    --with github.com/lucaslorentz/caddy-docker-proxy/[email protected] \
    --with github.com/caddy-dns/cloudflare

FROM caddy:${CADDY_VERSION}-alpine

RUN apk add --no-cache tzdata

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

CMD ["caddy", "docker-proxy"]

Hi! I am on the process to host a instance for a large subreddit to migrate to lemmy. I already played with hosting with docker before, and the ansible method seem even easier!

What I am concerned is about the storage. I need to have a way to calculate before hand because I am afraid of the costs.

I have an always free tier oracle cloud vps I could use, and buy some extra storage.

I haven't checked but are kbin instances easier to spin up? Kbin is be able to communicate with Lemmy communities without a problem.

Anyone know if setting up an instance via a shared Hostgator server is possible? I already pay for a plan for my personal site so wondered if I could add on a new domain plus a partition to it and take advantage to make my own instance for posting and browsing myself.

I was playing with the idea of spinning up a VPS through AWS lightsail since the bundled package it provides seems to be cheaper than configuring an EC2 instance/other requisite resources running 24/7.

What has been people's experience regarding:

• Monthly data upload rates (since most cloud providers charge internet egress per gigabyte)
• Database/image storage requirements