So far my experience with Nextcloud has been that it is a pain in the arse to install, and once it’s installed is slow as anything. Literally couldn’t run it on my pi 3b, now got it up and running pretty nicely on a NUC but it’s still not great. Have caching set up.

I have the notes app installed on my android phone and I can never used rich text editing because it gives timeout error.

This shouldn’t be this complicated. All I want is to de-Google my documents and notes, and self-host my kanban. I don’t really need the rest though it’s nice to have the options.

Do people use alternatives? Am I doing something completely wrong? I set it up using nginx which I know is not supported, but the alternative using Docker AIO didn’t allow me to use custom port easily.

  • sdw@lemmy.ca
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 year ago

    Just want to say that I’ve been there. There was a time my Nextcloud install was incredibly slow. Fortunately (or unfortunately?), it is featureful enough and widely supported that once you figure this issue out, it is a nice service to keep running.

    For me, adding Redis was essential. It doesn’t really make sense to me why (nothing I do on Nextcloud is intensive or data heavy) but it has greatly improved the performance of my app.

    My entire setup is a containerized Nextcloud, Nextcloud Cron, MariaDB (if I knew Postgres was an option, I would’ve chosen that), and Redis:

    version: '2'
    services:
      nextcloud:
        container_name: nextcloud
        image: nextcloud:27-apache
        restart: unless-stopped
        environment:
          - MYSQL_PASSWORD=nextcloud
          - MYSQL_HOST=db
          - MYSQL_DATABASE=nextcloud
          - MYSQL_USER=nextcloud
        labels:
          - 'public-service=true'
          - 'traefik.enable=true'
          - 'traefik.http.routers.cloud.rule=Host(`nextcloud.some.domain`)'
          - 'traefik.http.routers.cloud.tls=true'
          - 'traefik.http.services.cloud.loadbalancer.server.port=80'
        volumes:
          - /some/data/dir/nextcloud/data:/var/www/html
          - /some/external/dir:/wew:ro
    
      nextcloud-cron:
        image: nextcloud:27-apache
        restart: unless-stopped
        command: [/cron.sh]
        environment:
          - MYSQL_HOST=db
          - MYSQL_DATABASE=nextcloud
          - MYSQL_USER=nextcloud
          - MYSQL_PASSWORD=nextcloud
        volumes:
          - /some/data/dir/nextcloud/data:/var/www/html
          - /some/external/dir/:/wew:ro
    
      db:
        image: mariadb:10.4
        restart: unless-stopped
        environment:
          MYSQL_DATABASE: nextcloud
          MYSQL_USER: nextcloud
          MYSQL_ROOT_PASSWORD: nextcloud
        volumes:
          - /some/data/dir/nextcloud/db:/var/lib/mysql
    
      mysqldump:
        image: mariadb:10.4
        depends_on: [db]
        # restart: never # cronjob
        labels:
          - 'cron.schedule=0 0 8 * * ?'
        entrypoint: [mysqldump, -h, db, -u, nextcloud, -pnextcloud, --all-databases, -r, /out/nextcloud.sql]
        user: root
        volumes:
          - /some/data/dir/nextcloud/db-dump:/out
    
      redis:
        image: redis
        restart: unless-stopped
    
    • Giddy@aussie.zone
      link
      fedilink
      English
      arrow-up
      0
      ·
      1 year ago

      Can I ask why the separate NC container for cron? Also, I presume the mysqldump container is for easy db backups?

      • sdw@lemmy.ca
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        The separate cron container made the most sense to me. Other variants “work” but imo are mostly workarounds to avoid setting up a real cronjob. Beyond this I have no real reason, nor can I vouch that is is more or less performant than others.

        Yes, the mysqldump container is for easier restores. It’s much easier to restore from a .sql file than a raw data dir that was copied while the DB was running ;) (speaking from experience…)