Cloudron Forum

Updated Ente Package: andreasdueren/ente-cloudron:0.6.1

Fixes:

• Ente Locker now works: public-locker was incorrectly pointing to the embed app — it now correctly points to the share app (apps/share), which is the actual Public Locker frontend. This fixes Locker redirecting to the photos app.

Changes since 0.5.9:

• v0.6.0 — Fresh build with latest upstream ente sources
• Customize email footer for self-hosted instance (removes ente.io branding)
• Redirect base domain to photos host
• Fix Museum API matchers scoped to photos host
• v0.6.1 — Fix public-locker → share URL (Locker fix)

Upstream: https://github.com/ente-io/ente/commit/deb7314

@Divemasterza I really would have preferred R2 for this use case but oh well.

@James Why is it being abandoned?

@avatar1024 Still can recommend this one https://forum.cloudron.io/post/76397

@timconsidine Sorry about that, I moved from gitea to gitlab but only migrated the projects I'm actively working on. It's an interesting application but I don't have any current strict needs, the code is here for right now if you want to continue development: https://gitea.due.ren/andreas/openobserve-cloudron

@Divemasterza Which provider is this? R2 doesn't work, seemingly because it doesn't support the S3 POST Object operation

Edit:

Got Hetzner working with these Settings:

S3_BUCKET_NAME=redacted
S3_FORCE_PATH_STYLE=1
S3_ENDPOINT_URL=https://fsn1.your-objectstorage.com
S3_REGION=fsn1
S3_ACCESS_KEY=redacted
S3_SECRET_KEY=redacted

@girish Seems to work fine, thank you!

@girish I’ll try soon when I get a chance to monitor the update thank you

@Package-Updates Was the s3 provider script removed? This update broke my installation. @girish @nebulon ModuleNotFoundError: No module named 's3_storage_provider'

@scooke Which provider are you using? I tried R2 with no luck

@girish said in Let's Encrypt profiles:

use case

What about issuing a certificate for the IP address during initial setup? Would encrypt the initial admin credentials.

I did some digging, this is what I think is needed:

The current package uses:

• Synapse v1.144.0 (which is compatible - MAS requires v1.136.0+)
• Cloudron OIDC for SSO (traditional OIDC provider approach)
• PostgreSQL as the database
• Standard Matrix authentication endpoints

What MAS Integration Requires
MAS is fundamentally different from traditional OIDC - it's not just another identity provider, but a complete replacement for Synapse's internal authentication system per MSC3861. It needs:

1. MAS Service Deployment

• MAS needs to run as a separate service (not just a config change)
• It requires its own separate PostgreSQL database
• It needs its own domain/subdomain (e.g., auth.matrix.example.com)
• Docker image: ghcr.io/element-hq/matrix-authentication-service:latest

2. MAS Configuration Requirements

• Encryption secrets and signing keys (RSA minimum)
• Connection to Synapse via shared secret
• Database configuration for its own PostgreSQL database
• HTTP listener configuration
• Email configuration for password recovery
• Policy configuration (WASM file)

3. Synapse Configuration Changes
Replace traditional OIDC with matrix_authentication_service section:

matrix_authentication_service:
  enabled: true
  endpoint: http://mas-internal:8080/
  secret: "SharedSecretWithMAS"

4. Reverse Proxy Changes
These Matrix endpoints must be routed to MAS (not Synapse):

• /_matrix/client/*/login
• /_matrix/client/*/logout
• /_matrix/client/*/refresh

5. User Migration (For Existing Deployments)
MAS includes syn2mas tool to migrate:

• Existing password hashes (bcrypt → argon2id)
• Sessions and devices
• Access tokens
• Upstream IdP mappings

I packaged the Matrix Signal Bridge

Repo: https://git.due.ren/andreas/mautrix-signal-cloudron
Image: andreasdueren/mautrix-signal:1.0.2

@Eliahou I packaged the signal bridge and now wanted to see how I can make encryption work.

Root Cause: Synapse 1.141+ explicitly blocks appservice users from using /sync. The mautrix bridges were configured to poll /sync for encryption data, which caused HTTP 500 errors.
Solution: Enabled appservice mode for end-to-bridge encryption, which uses MSC3202/MSC2409 to receive encryption data via appservice transactions instead of /sync.

In specific this means:

Changes Made

1. Synapse:
   • Added experimental features to homeserver.yaml:

           experimental_features:
                 msc3202_transaction_extensions: true
                 msc2409_to_device_messages_enabled: true

• Added org.matrix.msc3202: true to both bridge registration files

2. Signal Bridge:
   • Updated start.sh to set encryption.appservice = true
   • Built and deployed andreasdueren/mautrix-signal:1.0.2
3. WhatsApp Bridge:
   • Updated start.sh to set encryption.appservice = true
   • Built and deployed andreasdueren/mautrix-whatsapp:2.0.2

Does anyone know if Bitwarden Lite includes the secrets manager? That would be an argument.

@Grienauer You need to put it into recovery mode, execure the script, take it out of it again

@james this won’t fix the issue of logging everyone out though I assume?

Edit: just saw the newest update.

Should be trivial to package. But what would be the benefits over vaultwarden?

I packaged this so I could test it:

https://git.due.ren/andreas/blinko-cloudron
andreasdueren/blinko-cloudron:20251230-014843-727262a70

Looks like it's a larger upgrade with various issues