95 comments

[ 2.2 ms ] story [ 90.7 ms ] thread
I'm still setting up my own home server, adding one functionality at a time. I wanted to like Nextcloud but it's just too bloated.

Radicale is a good calendar replacement. I'd rather have single-function apps at this point.

Could an installable PWA solve this ?
For reference, 20 MB is three hundred and thirteen Commodores.
I have been considering https://bewcloud.com/ + Immich as an alternative

Nextcloud's client support is very good though and it has some great apps, I use PhoneTrack on road trips a lot

PhoneTrack +1, if you don't mind some tinkering. It looks like a power tool someone made with great care.

I wish there was a better client-side view/share app. I've been meaning to try Dawarich, I've heard it does this better.

(comment deleted)
(comment deleted)
NextCloud does feel slow. What I want is not only a cloud service that does lots of common tasks, but it also should do it lightly and simply.

I'm extremely tempted to write a lightweight alternative. I'm thinking sourcehut [1] vs GitHub.

[1] https://sourcehut.org/

Take a look at OpenCloud. It's a Go-based rewrite of the former OwnCloud team.

It works very well, has polished UI and uses very little resources. It also does a lot less than Nextcloud.

https://github.com/opencloud-eu

Nextcloud not perfect but it's still one of a major project that has not shifted to business oriented licence and where all components are available and not paywalled with enterprise edition.

So yes not perfect, bloated js but it works and is maintained.

So I'd rather thanks all developers involved in nextcloud than whine about bloated js.

I'm curious how much Javascript eg gmail and google docs/drive give you, in comparison.
Does anyone know what they are doing wrong to create such large bundles? What is the lesson here?
I think, some of the issues here is that first nextcloud tries to be compatible with any managed / mutualized hosting.

They also treat every "module"/"apps" whatever you call it, as completely distinct spa without proving much of a sdk/framework. Which mean each app, add is own deps, manage is own build, etc...

Also don't forget that app can even be a part of a screen not the whole thing

On the same note a jira ticket as configured where I work the entire page is 42mb. And I use ad blockers so I already skip the page counting stuff
I would love to like Nextcloud, it's pretty great that it does exist. Just that makes it better than... well everything else I haven't found.

What frustrates me is that it looks like it works, but once in a while it breaks in a way that is pretty much irreparable (or at least not in a practical way).

I want to run an iOS/Android app that backs up images on my server. I tried the iOS app and when it works, it's cool. It's just that once in a while I get errors like "locked webdav" files and it never seems to recover, or sometimes it just stops synchronising and the only way to recover seems to be to restart the sync from zero. It will gladly upload 80GB of pictures "for nothing", discarding each one when it arrives on the server because it already exists (or so it seems, maybe it just overwrites everything).

The thing is that I want my family to use the app, so I can't access their phone for multiple hours every 2 weeks; it has to work reliably.

If it was just for backing up my photos... well I don't need Nextcloud for that.

Again, alternatives just don't seem to exist, where I can install an app on my parent's iOS and have it synchronise their photo gallery in the background. Except I guess iCloud, that is.

For photos, you can't beat Immich.
This also happened to me with my nextcloud, thankfully I did not lose any photos. I transitioned to Immich for my photos and have not looked back.
I switch to FolderSync for the upload from mobile. Works like a charm!

I know, it sucks that the official apps are buggy as hell, but the server side is real solid

Nextcloud is great, but I don't use it for backup (didn't realize it would even do that) so maybe that's why.

I use it for a family cloud service for chat, shared todo lists, shared calendar and shared editing docs (don't want to put anything private on e.g. google docs).

For all that, it's full of awesome.

You could set up Syncthing. Once properly configured (including ignored files, that have names that cannot be handled by the backing storage or clients), you shouldn't need to touch it much.
WebDAV is a nightmare, breaks when you least need it. Once I moved a few TB over it, it took a week with all the retries and troubleshooting.

As I understand it you can work around it with Nextcloud by running some other transfer service and have it watch and automatically import certain directories.

> The majority of CEO job is excellent judgement and motivating people.

Ain't that the problem with everything. They all look good on paper until you try it for a while.

All I know about Nextcloud is that HN is full of people complaining about Nextcloud
nextcloud just feels abandoned, even if it isn't of course.

maybe paying customers are getting a different/updated/tuned version of it. maybe not. but the only thing that keeps me using it is there isn't any real selfhosted alternatives.

why is it slow? if you just blink or take a breath, it touches the database. years ago i've tried to optimise it a bit and noticed that there are horrible amount of DB transactions there without any apparent reason.

also, the android client is so broken...

I've played around with many self-hosted file manager apps. My first one was Ajaxplorer which then became Pydio. I really liked Pydio but didn't stick with it because it was too slow. I briefly played with Nextcloud but didn't stick with it either.

Eventually I ran into FileRun and loved it, even though it wasn't completely open source. FileRun is fast, worked on both desktop and mobile via browser nicely, and I never had an issue with it. It was free for personal use a few years ago, and unfortunately is not anymore. But it's worth the license if you have the money for it.

I tried setting up SeaFile but I had issues getting it working via a reverse proxy and gave up on it.

I like copyparty (https://github.com/9001/copyparty) - really dead simple to use and quick like FIleRun - but the web interface is not geared towards casual users. I also miss Filerun's "Request a file" feature which worked very nicely if you just wanted someone to upload a file to you and then be done.

Copyparty can't (and doesn't want to) replace Nextcloud for many use cases because it supports one-way sync only. The readme is pretty clear about that. I'm toying with the idea of combining it with Syncthing (for all those devices where I don't want to do a full sync), does anybody have experience with that? I've seen some posts that it can lead to extreme CPU usage when combined with other tools that read/write/index the same folders, but nothing specifically about Syncthing.
> I also miss Filerun's "Request a file" feature which worked very nicely if you just wanted someone to upload a file to you and then be done.

With the disclaimer that I've never used Filerun, I think this can be replicated with copyparty by means of the "shares" feature (--shr). That way, you can create a temporary link for other people to upload to, without granting access to browse or download existing files. It works like this: https://a.ocv.me/pub/demo/#gf-bb96d8ba&t=13:44

I find the Nextcloud client really buggy on the Mac, especially the VFS integration. The file syncing is also really slow. I switched back to P2P file syncing via Syncthing and Resilio Sync out of frustration.
I once discovered and reported a vulnerability in Nextcloud's web client that was due to them including an outdated version of a JavaScript-based PDF viewer. I always wondered why they couldn't just use the browser's PDF viewer. I made $100, which was a large amount to me as a 16 year old at the time.

Here is a blog post I wrote at the time about the vulnerability (CVE-2020-8155): https://tripplyons.com/blog/nextcloud-bug-bounty

syncthing otoh barely even has a web ui, so it's really fast :-P
Is Nextcloud reliable enough for "production" use?

Last time I heard a certain privacy community recommended against Nextcloud due to some issues with Nextcloud E2EE.

Nextcloud, and before it Owncloud, have been "in production" in my household for nearly a decade at this point. There have been some botched updates and sync problems over the years, but it's been by far the most reliable app I've hosted.

In terms of privacy & security, like everything it comes down to risk model and the trade-offs you make to exist in the modern world. Nextcloud is for sharing files, if nothing short of perfect E2EE is tolerable it's probably not the solution for you, not to mention the other 99.999% of services out there.

I think most of the problems people report come down to really bad defaults that let it run like shit on very low-spec boxes that shouldn't be supported (ie raspi gen 1/2 back in the day). Installing redis and configuring php-fpm correctly fixes like 90% of the problems, other than the bloated Javascript as mentioned in the op.

End of the day, it's fine. Not perfect, not ideal, but fine.

I don't doubt that large amounts of javascript can often cause issues but even when cached NextCloud feels sluggish. When I look at just the network tab of a refresh of the calendar page it does 124 network calls, 31 of which aren't cached. it seems to be making a call per calendar each of which is over 30ms. So that stacks up the more calendars you have(and you have a number by default like contact birthdays).

The Javascript performance trace shows over 50% of the work is in making the asynchronous calls to pull those calendars and other network calls one by one and then on all the refresh updates it causes putting them onto the page.

Supporting all these N calendar calls is pulls individually for calendar rooms and calendar resources and "principles" for the user. All separate individual network calls some of which must be gating the later individual calendar calls.

Its not just that, it also makes a call for notifications, groups, user status and multiple heartbeats to complete the page as well, all before it tries to get the calendar details.

This is why I think it feels slow, its pulling down the page and then the javascript is pulling down all the bits of data for everything on the screen with individual calls, waiting for the responses before it can progress in many ways to make the further calls of which there can be N many depending on what the user is doing.

So across the local network (2.5Gbps) that is a second and most of it in waiting for the network. If I use the regular 4G level of throttling it takes 33.10 seconds! Really goes to show how bad this design does with extra latency.

Sync Conf is next week, and this sort of issue is so part of what I hope maybe can just go away. https://syncconf.dev/

Efforts like Electric SQL to have APIs/protocols for bulk fetching all changes (to a "table") is where it's at. https://electric-sql.com/docs/api/http

It's so rare for teams to do data loading well, rarer still we get effective caching, and often a products footing here only degrades with time. The various sync ideas out there offer such an alluring potential, of having a consistent way to get the client the updated live data they need, in a consistent fashion.

Side note, I'm also hoping the js / TC39 source phase imports proposal aka import source can help let large apps like NextCloud defer loading more of it's JS until needed too. But the waterfall you call out here seems like the real bad side (of NextCloud's architecture)! https://github.com/tc39/proposal-source-phase-imports

The thing that kills me is that Nextcloud had an _amazing_ calendar a few years ago. It was way better than anything else I have used. (And I tried a lot, even the calendar add-on for Thunderbird. Which may or may not be built in these days, I can't keep track.)

Then at some point the Nextcloud calendar was "redesigned" and now it's completely terrible. Aesthetically, it looks like it was designed for toddlers. Functionally, adding and editing events is flat out painful. Trying to specify a time range for an event is weird and frustrating. It's better than not having a calendar, but only just.

There are plenty of open source calendar _servers_, but no good open source web-based calendars that I have been able to find.

Having at some point maintained a soft fork / patch-set for Nextcloud.. yes, there is so much performance left on the table. With a few basic patches the file manager, for example, sped up by magnitudes in terms of render speed.

The issue remains that the core itself feels like layers upon layers of encrusted code that instead of being fixed have just had another layer added ... "something fundamental wrong? Just add Redis as a dependency. Does it help? Unsure. Let's add something else. Don't like having the config in a db? Let's move some of it to ini files (or vice versa)..etc..etc." it feels like that's the cycle and it ain't pretty and I don't trust the result at all. Eventually abandoned the project.

Edit: at some point I reckon some part of the ecosystem recognised some of these issues and hence Owncloud remade a large part of the fundamentals in Golang. It remains unknown to me whether this sorted things or not. All of these projects feel like they suffer badly from "overbuild".

Edit-edit: another layer to add to the mix is that the "overbuild" situation is probably largely what allows the hosting economy around these open source solutions to thrive since Nextcloud and co. are so over-engineered and badly documented that they -require- a dedicated sys-admin team to run well.

This is my theory as well. NC has grown gradually in silos almost, every piece of it is some plugin they've imported from contributions at some point.

For example the reason there's no cohesiveness with a common websocket bus for all those ajax calls is because they all started out as a separate plugin.

NC has gone full modularity and lost performance for it. What we need is a more focused and cohesive tool for document sharing.

Honestly I think today with IaC and containers, a better approach for selfhosting is to use many tools connected by SSO instead of one monstrosity. The old Unix philosophy, do one thing but do it well.

Two things:

1. Did you open back port request with these basic patches? If you have orders of magnitude speed improvements it would be aswesome to share!

2. You definitively don't need an entire sysadmin team to run nextcloud, in my work (large organisation) there's three instances running (for different parts/purposes of which only one is run by more than one person, and I run myself both my personal instance and for a nonprofit with ~100 persons, it's really not much work after setup (and other systems are plenty of a lot more complicated systems to set up, trust me)

I've never used nextcloud, but I always imagined that the point is you can run services but then plug in any calendar app etc. You don't have to be running nextclouds calendar, I thought. Did I misundestand how it works?
Nextcloud is bloated and slow, but it works and is reliable. I've been running a small instance in a business setting with around 8 daily users for many years. It is rock solid and requires zero maintenance.

But people rarely use the web apps. Instead, it's used more like a NAS with the desktop sync client being the primary interface. Nobody likes the web apps because they're slow. The Windows desktop sync client has a really annoying update process, but other than that is excellent.

I could replace it with a traditional NAS, but the main feature keeping me there is an IMAP authentication plugin. This allows users to sign in with their business email/password. It works so well and makes it so much easier to manage user accounts, revoke access, do password resets, etc.

Just like any other modern app: first you make it work using frameworks. Then, as soon as the "Core" product is done - just a few more features - then we'll circle back around to ripping out those bloated frameworks for something more lithe. Shouldn't be more than two weeks, now. Most of the base stuff is done. Just another feature or two. I mean, a little longer, if we have some issues with those features, sure. But we'll get back around to a simpler UI right after! Just those features, their bugs and support, and then - well documentation. Just the minimum stuff. Enough to know what we did when we come back to it. But we'll whip up those docs and then it's right on to slimming down the frontend! Won't be long now...
I've used nextcloud for close to I think 8 years now as a replacement for google drive.

However my need for something like google drive has reduced massively, and nextcloud continues to be a massive maintenance pain due to its frustratingly fast release cadence.

I don't want to have to log into my admin account and baby it through a new release and migration every four months! Why aren't there any LTS branches? The amount of admin work that nextcloud requires only makes sense for when you legitimately have a whole group of people with accounts that are all utilizing it regularly.

This is honestly the kick in the pants I need to find a solution that actually fits my current use-case. (I just need to sync my fuckin keepass vault to my phone, man.) Syncthing looks promising with significantly less hassle...

Might also consider Vaultwarden/Bitwarden as a self-host alternative. Yeah it's client-server... that said, been pretty happy as a user.
The linuxserver.io image for Nextcloud requires considerably less babysitting for upgrades: https://docs.linuxserver.io/images/docker-nextcloud

As long as you only upgrade one major version at a time, it doesn't require putting the server in maintenance mode or using the occ cli.

Been running NC on my home server and basically maybe update it once a year or so? Even less probably, so definitely not a must to update every time. Plus via snap it's pretty simple.
Been using syncthing with keepass(X/XC) for probably half a decade now and it works great, especially since KeepassXC has a great built-in merge feature for the rare cases that you get conflicts from modifying your vault on different clients before they sync.

The only major point of friction with syncthing is that you should designate one almost-always-on device as "introducer" for every single one of your devices, so that it will tell all your devices whenever it learns about a new device. Otherwise whenever you gain a device (or reinstall etc) then you have to go to N devices to add your new device there.

Oh, and you can't use syncthing to replicate things between two dirs on the same computer - which isn't a big deal for the keepass usecase and arguably is more of a rsync+cron task anyway but good to be aware of.

A good thing thing about Nextcloud is that by learning one tool, you get a full suite of collaboration apps: sync, file sharing, calendar, notes, collectives, office (via Collabora or OnlyOffice), and more. These features are pretty good, plus, you get things like photo management and Talk, which are decent.

Sure, some people might argue that there are specialized tools for each of these functions. And that’s true. But the tradeoff is that you'd need to manage a lot more with individual services. With Nextcloud, you get a unified platform that might be good enough to run a company, even if it’s not very fast and some features might have bugs.

The AIO has addressed issues like update management and reliability, it been very good in my experience. You get a fully tested, ready-to-go package from Nextcloud.

That said, I wonder, if the platform were rewritten in a more performance-efficient language than PHP, with a simplified codebase and trimmed-down features, would it run faster? The UI could also be more polished (see Synology DSM web interface). The interface in Synology looks really nice!

rewriting in a lower-level language won't do too much for NC, because it's mostly slow due to inefficient IO organization - things like mountains of XHRs, inefficient fetching, db querying etc. - None of that will be implicitly fixed by a rewrite in any language and can be fixed in the PHP stack as well. I think one of the reasons that helped OC/NC get off the ground was precisely that the sysadmins running it can often do a little PHP, which is just enough to get it customized for the client. Raising the bar for contribution by using lower level languages might not be a desirable change of direction in that case.