Restore SMTP username and password for authenticated relay on port
2525. According to Cloudron docs, this port should work with plain
SMTP and authentication without STARTTLS.
The STARTTLS port 2587 requires TLS certificate verification, but
Cloudron's internal mail relay uses a wildcard cert for *.due.ren
which doesn't match the hostname 'mail'. Port 2525 is the internal
plain SMTP relay that doesn't require authentication or TLS for
connections from within the same container network.
Switch from plain SMTP on port 2525 to STARTTLS on port 2587.
The Go smtp.SendMail function automatically handles STARTTLS
negotiation when encryption is empty, which is required by
Cloudron's sendmail addon on the STARTTLS port.
Configure Museum to use CLOUDRON_MAIL_SMTP_USERNAME and
CLOUDRON_MAIL_SMTP_PASSWORD for authenticated SMTP relay.
This fixes the "550 I cannot deliver mail" error by properly
authenticating with the Cloudron sendmail addon.
Change SMTP host from localhost/127.0.0.1 to 'mail' as per Cloudron
sendmail addon documentation. The sendmail addon provides a local SMTP
relay accessible via hostname 'mail' on port 2525.
Instead of trying to match the albums host with current host
(which always fails in path-based routing), use a dummy domain
'albums.localhost.invalid' that will never match the actual host.
This prevents the automatic redirect to /shared-albums.
Version bump to 0.3.2
The app was redirecting to /shared-albums because albumsAppOrigin()
returned the same host as the current URL after runtime replacement.
By setting NEXT_PUBLIC_ENTE_ALBUMS_ENDPOINT at build time to a
placeholder and replacing it at runtime with the full path-based URL,
the host comparison will fail and prevent the redirect loop.
Version bump to 0.3.1
- Fixed admin-helper.sh to use correct Museum binary path (/app/museum-bin/museum)
- Updated start.sh to handle missing S3 configuration gracefully
- App now starts in configuration mode when S3 is not configured
- Shows helpful configuration page instead of failing health checks
- Properly starts Museum server once S3 is configured
- Updated CloudronManifest.json to version 0.2.2
- All web frontends (photos, accounts, auth, cast, albums, family) verified working
- Museum API server running successfully with S3 storage
- Add specific _next asset routes for accounts, auth, cast apps
- Add image asset routes for each app
- Ensure each app's assets are served from correct directory
- Keep photos app routing unchanged
Should fix accounts/auth/cast apps loading issues.
- Change NEXT_PUBLIC_ENTE_ENDPOINT to relative /api for domain flexibility
- Remove runtime JS endpoint replacement (fragile, now unnecessary)
- Fix all domain references to use CLOUDRON_APP_DOMAIN consistently
- Add /ping health check endpoint to Caddy configuration
- Update placeholder server to use dynamic domain
Photos app now working, other apps may need additional fixes.
- Patch origins.ts during Docker build to use window.location.origin + '/api'
- Update version to 0.1.69 to force rebuild
- Add browser compatibility check for server-side rendering
- Fix both API and uploader endpoint redirections
This addresses the root cause where web apps were hardcoded to use
https://api.ente.io instead of the local Museum server.
- Fixed Next.js static asset (_next/*) routing for each app separately
- Updated app path handling to work with both /app and /app/* patterns
- Resolved 404 errors for static assets from auth, accounts, and cast apps
- Updated to version 0.1.66
- Added detailed API endpoint information in SETUP-INSTRUCTIONS.md
- Documented API usage with Ente CLI
- Enhanced routing configuration for auth/cast/accounts apps
- Updated to version 0.1.64
- Implement comprehensive OTP email monitoring service
- Monitor Museum logs for "Skipping sending email" pattern
- Send verification emails using Cloudron email addon
- Add specific regex pattern for Museum's skip email format
- Version bump to 0.1.62
The monitor captures OTP codes from logs when Museum skips sending
emails and sends them via Cloudron's email system. This ensures
users receive their verification codes even when Museum's email
configuration is not sending directly.
