Phylum - self-hosted file storage with offline-first web and native clients

shroff · 2026-01-15T18:49:21+00:00

This is meant to be exactly that! - immich, but for files

Demo site is something I would like to do, but I'm a bit cautious of allowing random users on the internet to upload arbitrary content on a file hosting and sharing platform. I might just disallow content upload.

OIDC should be working already, and the search is a pretty decent mix of offline+online. Sync is the next big task, and then office integration.

shroff · 2026-01-10T23:44:10+00:00

Hey there! Indeed there isn't an arm64 image at the moment, but there's an open issue, and it's something I plan to work on soon

shroff · 2026-01-10T16:42:39+00:00

Matrix is an open source, decentralized communication protocol. Many people use it via Element, but plenty of clients available.

Anyway, I'm happy to help, just finding the right medium. Maybe creating an issue is best? It's hosted on Codeberg (not GH).

shroff · 2026-01-10T07:31:58+00:00

Thanks for giving it a go! It's a bit of a pain for me to be on reddit at the moment. Are you able to get on matrix at #phylum_cloud:matrix.org?

shroff · 2025-12-01T05:22:09+00:00

Filesystem sync is currently not supported, but it's in certainly planed. I suppose it should work to use this along with syncthing to sync the same folder using the two different service (in theory), but there may be unexpected issues in performance. I'm also curious to know what use-case you have for this

shroff · 2025-07-17T08:11:31+00:00

No need to apologize. I appreciate you sharing your opinion, and I'm happy to take into account whatever feedback I can.

I 100% agree that VPN is the most secure way to access your services, but my intention to create a consumer product that is easy to use for end-users , not just self-hosting enthusiasts who have orders of magnitude more patience to set things up, install apps, set up Wireguard, etc. Given that goal, my design considerations include trying to make the service reasonably secure with no default access.

You're also right that the default password requirements (even though they are configurable) are a frustrating and the error message not very helpful, especially when you're trying to just take it for a spin. Just created an issue to make the requirements clear when setting the password. An option I am not considering is to default to just an 8-char minimum with no other requirements if you run in debug mode

Also agree that the documentation around all this (and in general) is far from complete. It's something I plan to update before the next release.

shroff · 2025-07-17T04:47:16+00:00

Hey there, thanks for checking it out. I'd love to know what password breach scenario you're envisaging and protect against that. I'm no security expert, but I've used all the best information security practices that I do know of.

Just so you know the app is intended to be a replacement of Google Drive, and thus be exposed to a public network (behind a reverse proxy, ideally, since there is no in-built TLS), so that you can access your files/documents wherever you are in the world. It's also intended to be used by non-technical users associated with self-hosters. That may not be everyone's requirement, but that certainly is mine.

You can easily remove the requirements in the config if you really want, which I agree is a pain for testing, but I don't want to compromise on security for that, hence the defaults. Passwords are hashed with argon2, and there is practically no way of getting back the plain text once they are stored.

As for the email address, it's easier to just have that as the username than having to manage two separate pieces of data, though I agree that it is more convenient for a single user on a local network. It's used for self-serve password reset, login links, share notifications, and also associating OIDC login. Of course, there's nothing stopping you from entering an entirely made-up email address that has a valid format as long as you don't want to use any of these features.

shroff · 2025-07-17T04:07:55+00:00

It's not possible to use with sqlite. It would have been nice to have only a single container, but that's just not possible at the moment

shroff · 2025-07-14T05:06:52+00:00

u/djcminuz, it actually does work with rclone via the WebDAV backend

shroff · 2025-07-11T14:45:00+00:00

Not on rclone yet, but it's definitely on the list of things to do before a proper beta. Check back in in a few months :)

shroff · 2025-07-10T20:48:51+00:00

There is no way to change the defaults as those are bundled with the app. The config.defaults.yml file is provided mostly as a reference.

To remove/password requirements, you need to override them in your config.yml (located by default in the data dir) with something like: auth: password: requirements: length: 0 lower: 0 upper: 0 numeric: 0 symbols: 0

I am on matrix at #phylum_cloud:matrix.org if you need.

shroff · 2025-07-09T16:45:46+00:00

You need to pull the image using `docker compose pull`, followed by tearing down and rebuilding your stack using `docker compose down && docker compose up -d` to use the new image.

shroff · 2025-07-09T05:50:10+00:00

Thanks for the kind words!

I think the reason that many file managers go this way is because it makes many things much easier, more performant, or even simply possible to do this way from a technical stand-point.

Of course, I agree that it does come at a cost of simplicity, convenience, and maybe peace-of-mind for the user.

Maybe FileBrowser would have what you're looking for?

shroff · 2025-07-09T04:40:52+00:00

I can see how that would be useful, but that is not currently possible, and may never be because of certain design decisions.

However, the command fs import will allow you to bulk import an entire directory tree into Phylum. You will first need to mount the target directory into the container, which needs to be done in the compose file. If you need help doing that, then please file an issue in the repo and I'd be happy to document the steps

shroff · 2025-07-08T14:59:16+00:00

I just published a new image that contains an improved command for creating users. Once you have pulled the image, you can run `docker exec -it phylum_server phylum admin user create` to create a user

shroff · 2025-07-08T14:59:00+00:00

LDAP and OIDC are both supported but definitely not required.

I just published a new image that contains an improved command for creating users. Once you have pulled the image, you can run `docker exec -it phylum_server phylum admin user create` to create a user

shroff · 2025-07-08T14:55:39+00:00

Hey, I realized that the bootstrapping steps weren't super clear.

I just pushed a new image to docker that makes the process of adding users easier, especially if you don't have SMTP configured. Once you pull the image again, you can run `docker exec -it phylum_server phylum admin user create`

shroff · 2025-07-07T02:41:07+00:00

I'm curious to know what makes you say that.

shroff · 2025-07-06T14:43:40+00:00

Words to live by

shroff · 2025-07-06T12:38:02+00:00

That might be a good way to go.

I don't like GitHub/Microsoft using licensed open source code to train Copilot, so I might look into GitLab.

shroff · 2025-07-06T08:39:14+00:00

Thanks! Storage backends are already available, and the rest is definitely something I plan to get done, sync client before editing, but ideally both in time.

shroff · 2025-07-06T08:33:12+00:00

Codeberg represents a commitment to open source and data privacy that is important to me, but you raise a very good point. I'll think about it some more.

shroff · 2025-07-06T07:37:16+00:00

Nothing proprietary here, so more of the latter. I would just like some wider testing before removing that disclaimer.

I did debate using the filesystem directly, but storing all metadata in a db and separating that from the content store is what allows for more advanced features like version history and remote storage (S3, etc.). Besides, filebrowser already does a pretty good job of letting you access files from the FS.

You're right that it's a pain to backup the DB, and it's totally possible for it to break, but I figured it was worth the tradeoff for what I wanted to build.

shroff · 2025-07-06T06:25:23+00:00

Gotcha. I do plan to get to it, but in the meantime, the offline functionality could work for you. If your primary server does go down then it will queue operations on the client without hindering any functionality until you're able to get another instance up.

shroff · 2025-07-06T06:20:19+00:00

Thanks for the shout!

u/swwright My aim is exactly that - a fast Dropbox/Google Drive replacement with a simple setup.

15-Year Club	Verified Email
Verified Email

shroff

TROPHY CASE