Thank you for working on this. As a long term user of Nextcloud, I appreciate alternatives. Nextcloud is a beast with a lot of features but most of the folks I know including me use it mostly for files so projects like these can be useful.<p>Most lightweight alternatives I found use some non standard format to store files instead of leaving it to the filesystem which keeps me away from using those. I am glad bewCloud is not doing that.
Thanks for the kind words! Yes, indeed I find that keeping a separate state for the filesystem isn't necessary (if you can/want to leverage other great tools for searching, like `find` and `grep`).
The following command from the README.md for the initial setup failed:<p><pre><code> docker compose run --rm website bash -c "cd /app && make migrate-db"
make: *** No rule to make target 'migrate-db'. Stop.
</code></pre>
Instead I had to run this:<p><pre><code> docker compose run --rm -it website bash -c "cd /app && deno --allow-read --allow-env --allow-net migrate-db.ts"</code></pre>
And then whenever I went on <a href="http://localhost:8000/files" rel="nofollow">http://localhost:8000/files</a> I had the following error:<p><pre><code> An error occurred during route handling or page rendering.
</code></pre>
With this in the logs:<p><pre><code> website-1 | 2025-02-21T14:40:01.285Z - [303] GET http://localhost:8000/
website-1 | 2025-02-21T14:40:01.316Z - [200] GET http://localhost:8000/dashboard
website-1 | 2025-02-21T14:40:01.465Z - [200] GET http://localhost:8000/styles.css
website-1 | An error occurred during route handling or page rendering.
website-1 | PermissionDenied: Permission denied (os error 13): mkdir '/app/data-files/e5f69a80-249a-4845-a6d4-2a4911f9e249/.Trash/'
website-1 | at async Object.mkdir (ext:deno_fs/30_fs.js:200:3)
website-1 | at async getPathEntries (file:///app/lib/data/files.ts:73:9)
website-1 | at async getDirectories (file:///app/lib/data/files.ts:13:29)
website-1 | at async GET (file:///app/routes/files.tsx:33:29)
website-1 | at async handleLogging (file:///app/routes/_middleware.tsx:66:22)
website-1 | at async handleContextState (file:///app/routes/_middleware.tsx:60:22)
website-1 | at async handleCors (file:///app/routes/_middleware.tsx:25:22)
website-1 | at async handler (https://deno.land/x/fresh@1.7.3/src/server/context.ts:295:14)
website-1 | at async mapped (ext:deno_http/00_serve.ts:391:18) {
website-1 | name: "PermissionDenied",
website-1 | code: "EACCES"
website-1 | }
</code></pre>
I tried to chown it, didn't help. I tried other things within the container (docker compose run -it website /bin/sh), see this discussion to see what I tried:<p><a href="https://chatgpt.com/share/67b890cb-0574-800d-a0ac-470e40891717" rel="nofollow">https://chatgpt.com/share/67b890cb-0574-800d-a0ac-470e408917...</a>
yeah, docker and permissions always a pain. you tried passing --user or through compose? [1]:<p><pre><code> my-service:
image: ubuntu:latest
user: ${MY_UID}:${MY_GID}
volumes:
- /etc/passwd:/etc/passwd:ro
- /etc/group:/etc/group:ro
</code></pre>
[1] <a href="https://stackoverflow.com/a/71027261" rel="nofollow">https://stackoverflow.com/a/71027261</a><p>hope this helps/solves
> Since I'm not into reinventing the wheel, I don't think I'll work on bringing Contacts/CardDav or Calendar/CalDav back into it.<p>I initially ran Nextcloud in order to have a self-hosted Dropbox replacement but the shared calendar and excellent web UI eventually became the killer app for our family. We ended up not really using any other part of Nextcloud.<p>Unfortunately, Nextcloud revamped the calendar UI to the point that it's actively painful to use.<p>There are _lots_ of open-source Dropbox-like solutions for file sharing, but if I could find a good shared calendar solution _with a decent web UI_, then I could ditch Nextcloud from my self-hosted stack.
Thanks! As I mentioned, while I did have a working web UI, it wasn't full-featured (recurring events couldn't be created with complex settings or anything like that), and since my family and I use the native desktop/mobile calendar clients, it seemed unnecessary, once I got Radicale working for the server part. Do you not have/use the native clients?<p>In any case, you're welcome to check the commit where I left that off [1].<p>[1] <a href="https://github.com/bewcloud/bewcloud/releases/tag/v0.0.1-self-made-carddav-caldav">https://github.com/bewcloud/bewcloud/releases/tag/v0.0.1-sel...</a>
Any and all activity in this domain is appreciated! I used to run Nextcloud for a few companies but.. it's just subpar and like OP rightly states the complexity inherited is out of this world.
The images load very slowly. Perhaps you could downsize them a little? The first one I clicked on was 3283x2015 pixels, way too large for something that occupies maybe a quarter of my screen.
> Look no further than bewCloud – an innovative, open-source cloud solution crafted with TypeScript and Deno, using Fresh.<p>This looks interesting and is a space in which I'm definitely interested, but if you're targeting simplicity, I didn't think focusing on the programming tools is the right way to pitch your product.
Stating that one of the problems with Nextcloud is PHP does not inspire confidence.
If it's not clear, it's a problem "to me". I've worked with PHP for over 10 years but I don't like it as much as TypeScript, Ruby, Rust, Python, or Go, for example.
I'm yet to figure out why we keep chasing this notion that everything should be on the cloud.<p>StarOffice/LibreOffice was open sourced 25 years ago. It is still maintained and developed to this day. It can run on any operating system you need, and it uses the same data formats that any "cloud solution" will use as well.<p>It can not be a matter of "it doesn't have online multi-writer collaboration tools", because if that was such a killer feature, there would be at least a handful of companies developing plugins to support this - or even developed in the project itself.<p>It can not be a matter of "data always available online", because you could solve this with a virtual online drive that can be browsed and/or synced with your work computer.<p>The funny thing to me is that mobile-first people <i>prefer</i> to have an app for each separate task, while PC-first people would rather have everything inside a browser window.
> It can not be a matter of "data always available online", because you could solve this with a virtual online drive that can be browsed and/or synced with your work computer.<p>That's exactly my reason for using nextcloud and other apps like that though.<p>I want to be able to browse my own files from my phone or any other safe device, and that's what nextcloud offers. It is literally a "virtual online drive that can be browsed and/or synced" with any device, much like bewcloud.<p>I personally use nextcloud because I am using its other features as well, and there is no denying it suffers from being a jack of all trades, master of none, but having your data in the cloud, being able to access you admin paperwork, share data with your relatives or even random people, or manage a calendar amongst several people is a fairly frequent use case.
> I want to be able to browse my own files from my phone or any other safe device<p>How much data do you have? Why not simply <i>replicate</i> this data between your devices?<p>My "office documents" are ~4.8GB, according to the file browser. I simply just have it on Syncthing and copy everything to phone/laptop/workstation/NAS.
With personal photos, PDFs and everything, that's 3-4TB. With pure documents, that's still around 100-200GB.<p>The thing is, I don't know what I will need at a given time so I cannot just have a subset synced. Like when some friends I am visiting abroad wanted to have pictures of my house, or of an event we did with our children, now I can browse through them live.
> I'm yet to figure out why we keep chasing this notion that everything should be on the cloud.<p>In the old days, the browser was a way to get apps/services to users in way where dealing with Microsoft was reduced to the least possible. Microsoft knew this, that's why it kept IE6 broken for so long.<p>These days, it's a way to get apps/services to users without dealing with app stores or having to care about the platform at all - which may be desktop or mobile these days.<p>Also no one wants to carry storage devices with them any more. I really don't want this to be the case but I bet in 10 years USB flash drives and SD cards stop being a thing.<p>PCs are no longer the main computing device of the masses.
> Also no one wants to carry storage devices with them any more.<p>I don't think that's an active choice. I think this is something that Google and Apple keep pushing for the same reason that MS kept "IE6 broken for so long": the less available storage on the phone, the more people are locked to their cloud services.<p>> PCs are no longer the main computing device of the masses.<p>Sure, but we are talking about "Office suite in the cloud" here. Of course you are going to hear the exceptional case of someone that writes their own novels or powerpoint presentations on their phone, but I'm willing to bet that the for the majority of office workers, their main method of interacting with the application is through a big screen PC + keyboard and mouse.
it's a part of the bigger picture of IT architecture<p>How much should things (data/ compute/ infrastructure) be distributed vs centralised<p>There's no definitive answer, but there's trends which change over time or should i say they go around and around<p>Almost like reinventing the circle every few years, because old = bad, new = good
Looks interesting, I'm curious how you settled on WebDAV? A decade ago I built a NextCloud alternative backend that also used WebDAV, and I'm not sure it's something I would ever touch again. Lots of clients say they support WebDAV but they all do slightly different things, and if you own the clients then there are probably simpler protocols.
Reading the specs and lots of reverse-engineering multiple different popular clients. You can see most of it at <a href="https://github.com/bewcloud/bewcloud/blob/main/routes/dav.tsx">https://github.com/bewcloud/bewcloud/blob/main/routes/dav.ts...</a><p>The desktop app uses WebDAV for the sync (via rclone) just because it was the simplest and most reliable way, but the listing of directories (to choose sync) and the mobile app use a simple HTTP API.
This looks great.<p>Another simple alternative to nextcloud is using syncthing with a server as a peer. If you want a web interface, you can point a web file manager like FileGator to the sync'd folder.
Yes, if you're simply doing files! I explored that as well, but wanted News (RSS reader), Notes, and Photos.
Why do they keep using the word cloud for these kind of http file and application servers? There is nothing "cloudy" about them.<p>Only the actual managed services could reasonably be called cloud computing when they are hosted in an elastic and scalable infra.
Because they are your "own cloud" vs. the Big Tech cloud services. The meaning of words change and a person not in tech would never call something "an application server", which is perfectly fine.
Most people not in tech don't even know the word cloud in a context related to computing anyway. They know google drive/workspace, Microsoft 365, dropbox, that's it.<p>EDIT: OK not living in the Apple ecosystem I realize I forgot about icloud which at least in term of market shares in the USA is a big thing (but not necessarily everywhere else).
I thought 'the cloud' meant 'someone else's computer', but in light of personal cloud software like this, I might have to change that. 'Some other computer across a network', maybe?
<a href="https://en.wikipedia.org/wiki/Semantic_change" rel="nofollow">https://en.wikipedia.org/wiki/Semantic_change</a>
"What's wrong with Nextcloud or ownCloud?<p>To start, their resource footprints (CPU, memory) are huge when idle."<p>I've recently imported something like 2TB into a NextCloud instance on a Debian system. It idles at 0% CPU and 2GB RAM.<p>I would not choose JavaScript over PHP on the server.<p>How are you testing security? Do you have a security background?
It's good you got it to perform in a way you like it, it hasn't been my experience for many years, but I also haven't ran Nextcloud in the last 10 months.<p>I do have a lot of security and cryptography experience, and the TypeScript in the backend is a personal preference, which is improved, in terms of security, by using Deno instead of Node.js, but I mention it and agree it's a preference.
I'm curious about encryption with this or any similar service. My understanding with NextCloud is it can be set up with encryption such that the server cannot access the data.
bewCloud doesn't offer any server-side or end-to-end encryption (only in the HTTPS/SSL sense, and that's from caddy in the recommended docker-compose.yml file).<p>I also created and maintain an open source end-to-end encrypted product, Budget Zen [1], and it's just a different kind of beast.<p>Applying either concept here would be very complicated and complex.<p>To get an idea, Nextcloud offers server-side encryption and end-to-end encryption add-ons (apps), but they often cause issues with data becoming irrecoverable [2] [3] or simply not being compatible with mobile/desktop apps or other plugins/apps. And they have many years, many people, and a lot of money to throw at the problem.<p>[1] <a href="https://budgetzen.net" rel="nofollow">https://budgetzen.net</a><p>[2] <a href="https://help.nextcloud.com/t/recover-encrypted-files-after-lost-config-php/73297" rel="nofollow">https://help.nextcloud.com/t/recover-encrypted-files-after-l...</a><p>[3] <a href="https://help.nextcloud.com/t/all-files-lost-after-encryption/205135" rel="nofollow">https://help.nextcloud.com/t/all-files-lost-after-encryption...</a>
I like the current approach with focus on plain file sync and sharing. Keep it up!<p>I typically self host with full disk encryption which I trust more than application level encryptions. Guessing that works for most self hosters
Thank you for the thoughtful reply! Yeah, it is a very difficult problem, so I always hope there is somebody who will solve it for me.<p>I've been avoiding Nextcloud (because of their suggestion to run a Docker container with access to the Docker socket), so luckily I have not suffered any data loss, but I appreciate being informed of the risks there also.<p>Certainly having a targeted scope like on your other project helps reduce the complexity of the implementation and can turn it from unapproachable to viable.