How to configure Quepid for SSL and HTTPS
These directions assume you haven't enabled sending emails from Quepid. If you send emails you MUST set your public url as
QUEPID_DOMAINso that links are properly created.
Running Quepid Directly on HTTP
When deploying Quepid in a development or internal environment where HTTPS is not required, you can run the application directly on HTTP without any special configuration. Simply leave both FORCE_SSL and ASSUME_SSL unset (or set to false), and do not set QUEPID_DOMAIN. Rails will generate relative URLs for all assets and in-app links, which will automatically use the HTTP protocol of the current request. This configuration is suitable for local development, internal networks, or testing environments where SSL termination is not a concern.
Deploying Behind an SSL-Terminating Reverse Proxy
For production deployments where Quepid runs behind a reverse proxy like nginx or Apache that handles SSL termination, set ASSUME_SSL=true and configure QUEPID_DOMAIN to your public domain (e.g., quepid.example.com). The ASSUME_SSL setting tells Rails to trust the X-Forwarded-Proto header from your proxy and generate HTTPS URLs even though Quepid itself is running on HTTP internally. Your reverse proxy should be configured to set the X-Forwarded-Proto: https header when forwarding requests. This is the recommended configuration for most production deployments, as it allows your infrastructure to handle SSL certificates and termination while Quepid generates all public-facing URLs with the correct HTTPS protocol.
Using QUEPID_PROTOCOL for Proxies Without Header Support
Every once in a while you are behind a load balancer that doesn't set the X-Forwarded-Proto header, and then Quepid will assume http. In that case you need to use QUEPID_PROTOCOL=https as an explicit override. Set both QUEPID_DOMAIN to your public domain and QUEPID_PROTOCOL=https, and leave ASSUME_SSL unset. This tells Rails to always generate HTTPS URLs for assets and emails regardless of the incoming request protocol or headers.
This configuration is useful for legacy proxy setups, CDNs, or load balancers that don't properly forward protocol headers, ensuring that all generated URLs use HTTPS even when Rails cannot automatically detect it from the request context.