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
Nginx Static HTML Server
🔥 Description
This role configures an Nginx server to host a static HTML homepage securely over HTTPS. It automates domain configuration, SSL/TLS certificate retrieval using Let's Encrypt, and ensures your site is ready for production with minimal setup.
📖 Overview
Optimized for Archlinux environments, this role provides a lightweight, reliable solution for serving static websites. It automatically configures Nginx to serve files from a predefined directory, sets up secure HTTPS connections, and includes support for .well-known paths required by ACME challenges.
Key Features
- Static Site Hosting: Serves HTML, CSS, JavaScript, and other static files.
- Let's Encrypt Integration: Automatically requests and installs SSL/TLS certificates.
- Simple Root Configuration: Defines a clean webroot with
index.htmlsupport. - Secure by Default: Includes modern SSL headers and best practices via Nginx.
- .well-known Support: Ensures full ACME challenge compatibility.
🎯 Purpose
The Nginx Static HTML Server role provides a simple and efficient method to publish static websites with HTTPS, perfect for personal homepages, landing pages, or small projects.
🚀 Features
- Automatic HTTPS Certificates: Handles secure certificate issuance via Let's Encrypt.
- Minimal Nginx Setup: Clean and optimized default configurations.
- Highly Portable: Works out-of-the-box with minimal variables.
- Local Time Support: Properly displays directory listing timestamps when needed.
🔗 Learn More
🧑💻 Author Information
Created in 2023 by Kevin Veen-Birkenbach