Kevin Veen-Birkenbach
007963044b
Unify reverse proxy handling across apps via sys-stk-front-proxy and cleanly separate internal docker nginx configs from external vhosts. Changes: - docker-compose: use with_first_found for optional env and docker-compose.override files so roles can provide either a template or a static file without noisy 'Could not find or access' failures. - sys-stk-front-proxy: remove front_proxy_domain_conf_src and switch nginx vhost rendering to with_first_found over app-specific proxy.conf.j2 and the generic roles/sys-svc-proxy vhost flavour; keep health-check and handler logic unchanged. - web-app-nextcloud: migrate to sys-stk-full-stateful (front proxy + DB + docker), move internal nginx config to docker.conf.j2 under the volume path, and rename host.conf.j2 to proxy.conf.j2 for the external vhost. - web-app-magento: rename nginx.conf.j2 to docker.conf.j2 and update the runtime template task accordingly to make the intent (internal nginx) explicit. - web-app-matrix: rename nginx.conf.j2 to synapse.conf.j2 and adjust the webserver task to use the new template name for the synapse vhost. - web-app-bridgy-fed & web-app-flowise: pass domain and http_port explicitly when including sys-stk-front-proxy so the front stack has all required context. - web-svc-cdn/file/html: replace direct sys-stk-front-base + sys-util-csp-cert + nginx.conf.j2 handling with sys-stk-front-proxy and proxy.conf.j2, relying on the shared front-stack for TLS/CSP/vHost wiring. - web-svc-collabora: drop the direct nginx.conf.j2 vhost generation and rename it to proxy.conf.j2 so it is picked up by sys-stk-front-proxy like other services. - web-opt-rdr-domains: rename redirect.domain.nginx.conf.j2 to redirect-domain.conf.j2 and adjust the task for clearer and more consistent naming. Context: see ChatGPT refactor discussion on 2025-11-30 (proxy unification, Collabora/Nextcloud/CDN stacks, CSP/header handling): https://chatgpt.com/share/692c64ea-a488-800f-ad42-7f7692a3742f
Matrix
Description
Step into the future of communication with Matrix, a dynamic and decentralized platform that delivers secure, real-time messaging and collaboration. With robust federation, end-to-end encryption, and versatile bridging support, Matrix enables seamless connections across diverse networks while safeguarding your data.
Overview
This role deploys a Matrix homeserver using Docker Compose, setting up the Synapse server along with essential components such as bridges and the Element web client. Matrix is built to support secure, decentralized communications with high performance and scalability.
For detailed configuration and operational instructions, please refer to the following files in this directory:
Features
- Decentralized and Federated: Connect with a global network of Matrix homeservers, ensuring there is no single point of failure.
- End-to-End Encryption: Protect your communications with robust encryption mechanisms to keep your messages private.
- Interoperability: Bridge communications with external platforms, allowing seamless interaction across different messaging systems.
- Scalable Architecture: Designed to handle increasing user loads and message volumes with high performance.
- Flexible Client Support: Access Matrix services via modern web clients like Element, which offer an intuitive and real-time user experience.
Further Resources
Credits
Developed and maintained by Kevin Veen-Birkenbach.
Learn more at veen.world.
Part of the Infinito.Nexus Project
Licensed under Infinito.Nexus NonCommercial License.