withinboredom
commented
4 months ago You could also just pass an environment value: SERVER_NAME=:8095, for example. The server-name is a lot like nginx's "location" block. So, if you are familiar with that, you basically told the server to listen to that port, no matter what the current address is. The default is localhost, so it would only do anything for connections on the local machine. If the server is directly connected to the internet, vs. behind a load balancer, you could also set it to SERVER_NAME=my-website.example.com and it would handle certificates, HTTP(s) 1, 2, & 3, auto-redirect to https, etc. It's designed to live on the edge of the network vs. behind load balancers (though it does that fine as well). Using modules like s3-storage, you can run multiple instances of the server and it will share certificates between the instances. Caddy is pretty neat.
StephenMiracle
What happened?
I tested a deployment of the FrankenPHP server into AWS EC2 & Fargate and wasn't able to get passed a blank "white" screen until I made a modification on the Caddyfile. I created a port reference :8095 and forwarded all requests to that location. It worked well, but not sure if there's a better way to handle these cases.
The reason for the failure is that the services are behind a load balancer & uses ephemeral IP addresses that I won't know until deployment.
The other option that I see working is requiring a static IP in my AWS deployment. This could make sense in some cases, but I don't know if it needs to be that way for all cases.
Thanks for any input.
Here's a link to Caddyfile for reference: https://github.com/StephenMiracle/wordpress-docker-frankenphp/blob/main/Caddyfile
Build Type
Docker (Debian Bookworm)
Worker Mode
No
Operating System
GNU/Linux
CPU Architecture
x86_64
Relevant log output
No response