I finally figured out how to package Armadietto for Cloudron, which is a self-hosting one-click installer; there was a similar attempt for Yunohost. The code is mostly a simplified version of the original Dockerfile.
I’m able to run it but confused because the REAMDE says the Dockerfile is for ‘monolithic’, which implements an older version of the spec (draft-dejong-remotestorage-01), so why does it seem work with my apps? Or more important for me, how can I know what might work differently? It seems like my apps can read/write data to the same place without issue but it’s hard to anticipate whether I will have surprises in the long-term. Maybe it makes sense to fork/archive ‘monolithic’ if there’s not much shared code with the ‘modular’ version to avoid any false sense of compatibility.
Also is there a Dockerfile for ‘modular’?
1 Like
That’s fantastic! 
Maybe @DougReeder can shed some light on which newer RS protocol features were added to the “modular” version?
Server variants
from the README:
Modular (new) Server
- Streaming storage (documents don’t have to fit in server memory)
- S3-compatible storage (requires separate S3 server; AWS S3 allows documents up to 5 TB)
- Can run multiple application servers to increase capacity to enterprise-scale
- Bug Fix: correctly handles If-None-Match with ETag
- Bug Fix: returns empty listing for nonexistent folder
- Implements current spec: draft-dejong-remotestorage-22
See the modular-server-specific documentation for usage.
Monolithic (old) Server
- Stores user documents in server file system
- More thoroughly tested
- Implements older spec: draft-dejong-remotestorage-01
See the monolithic-server-specific documentation for usage.
Compatibility
The spec differences are very small — I don’t know of any apps that work with one that don’t work fine with the other.
Future plans
I think we’ll be keeping both versions for a while — the monolithic server has no external dependencies and is good for personal installations, while the modular server better matches the needs of most organizations. If someone wants to write a filesystem streaming store for the modular server (which should be straighforward), and there is more usage of the modular version to flush out any possible bugs, we could retire the monolithic version.
The terminology is confusing; I’m thinking we should call the monolithic server the “classic” server, and the modular server the “Express” server.
Containerization
The current Dockerfile is for the monolithic server, as the modular server post-dates the start of work on the Dockerfile.
I have a Dockerfile for the modular server, but have waited to submit a PR, as I’m still doing final testing in Kubernetes. I can submit that PR within a week or two.
2 Likes
@DougReeder thanks for writing this up 
This is exactly what I was wondering. I tried comparing the drafts and it seems like there’s a lot of changes, but I wasn’t able to read and understand everything at the moment. It’s re-assuring to hear that apps can work with either.
Shall I PR that into the documentation somewhere? Might be good context.
Amazing! Looking forward to trying that out.
I don’t know that we need to steer people toward one or the other by their organizational size; both are good for small and medium size groups. The key decision point is usually whether the documents reside on the local disk or S3-compatible storage. Streaming storage won’t be a major point until there is a remoteStorage photo or video app
One question: if the plan is to keep the classic server around, wouldn’t it be somewhat important to backport the two bugfixes mentioned in the differences, since they look fairly critical for ensuring correct and efficient sync between clients and servers?
