Using current main docker image breaks with custom Caddyfile

[mristau]

When i switched to ghcr.io/pelican-dev/panel:main for testing plugins it did at first produce error 502 because after all Caddy didn't start

I was running with a custom Caddyfile, used almost identical to the one in the regular installation docs, but now that i had time i also tried it with an exact copy from the latest repo, both lead to the errors above.
When i remove the Caddyfile volume, it works again

https domain found setting email var
running behind proxy
listening on port 80 internally
Starting PHP-FPM and Caddy
Starting Supervisord
{"level":"info","ts":1781527801.6152918,"msg":"maxprocs: Leaving GOMAXPROCS=10: CPU quota undefined"}
{"level":"info","ts":1781527801.6155524,"msg":"GOMEMLIMIT is updated","package":"github.com/KimMachineGun/automemlimit/memlimit","GOMEMLIMIT":45421269811,"previous":9223372036854775807}
{"level":"info","ts":1781527801.6156096,"msg":"using config from file","file":"/etc/caddy/Caddyfile"}
{"level":"info","ts":1781527801.6158483,"msg":"maxprocs: No GOMAXPROCS change to reset"}
Error: adapting config using caddyfile: server block without any key is global configuration, and if used, it must be first

[parkervcp]

@mristau Can you share the caddy file you are using. Replace anything you want to keep private.

[mristau]

that is my full Caddyfile, but the error is the same when i am using this one https://github.com/pelican-dev/panel/blob/main/docker/Caddyfile

{
	servers {
		{$CADDY_TRUSTED_PROXIES} 
		{$CADDY_STRICT_PROXIES}
		timeouts {
			read_body 120s
		}
	}
	admin off 
	{$CADDY_AUTO_HTTPS} 
	{$CADDY_LE_EMAIL}
}

{$CADDY_APP_URL} {
	root * /var/www/html/public
	encode gzip
	file_server

	php_fastcgi 127.0.0.1:9000 {
		root /var/www/html/public
		index index.php

		env PHP_VALUE "upload_max_filesize = 256M
		post_max_size = 256M
		memory_limit = 512M"
		env HTTP_PROXY ""

		read_timeout 300s
		dial_timeout 300s
		write_timeout 300s
	}

	header Strict-Transport-Security "max-age=16768000; preload;"
	header X-Content-Type-Options "nosniff"
	header X-XSS-Protection "1; mode=block;"
	header X-Robots-Tag "none"
	header Content-Security-Policy "frame-ancestors 'self'"
	header X-Frame-Options "DENY"
	header Referrer-Policy "same-origin"

	request_body {
		max_size 256M
	}

	respond /.ht* 403

	log {
		output file /var/log/caddy/caddy.log {
			roll_size 50MiB
			roll_keep_for 7d
		}
		level ERROR
	}
}

[Randymartin1991]

I noticed that you need an additional environmental value when running it behind a reverse proxy.
BEHIND_PROXY=true

Troubleshooting with out enemy Mister AI:

The interesting thing is that the documentation and the image behavior don't quite match.

From the entrypoint.sh you posted, we can see the image explicitly supports:

if [ "${BEHIND_PROXY}" = "true" ]; then
export CADDY_LE_EMAIL=""
export CADDY_APP_URL=":80"
export CADDY_AUTO_HTTPS="auto_https off"
export ASSET_URL="${APP_URL}"
fi

and earlier:

if [ -z "${LE_EMAIL}" ] && [ "${BEHIND_PROXY}" != "true" ]; then
exit 1
fi

So BEHIND_PROXY is definitely a supported environment variable—it's just not documented on the Docker page you were following.

I suspect this is a documentation gap

The docs explain how to mount a custom Caddyfile behind a reverse proxy, but the current image's entrypoint also requires BEHIND_PROXY=true to suppress its automatic HTTPS logic. Without it, the container assumes it should manage Let's Encrypt itself.

Because we found it by inspecting the image, not by guessing, I'd consider this a documentation issue upstream.