Default self-hosted Docker Compose setup generates HTTPS asset URLs while only serving HTTP

[kerunix]

b10cks version

2026.8.25-1571e931

Install method

One-line installer (get.b10cks.com)

PHP version

PHP 8.5.9 (cli)

Database

image: mariadb:11.4

Steps to reproduce

1. Install with one liner
2. Navigate to /b10cks directory
3. Run docker compose exec app php artisan tinker \ --execute='dump(app()->environment(), config("app.url"), url("/build/test.js"));'

Expected behavior

"production"
"http://localhost:8000"
"http://localhost:8000/build/test.js"

Actual behavior

"production"
"http://localhost:8000"
"https://localhost:8000/build/test.js"

Logs or screenshots

When going to http://localhost:8000 the browser then raises CORS errors `Cross-Origin Request Blocked … CORS request did not succeed. Status code: (null)`

I understand why the default setup would be `production`, however I think that allowing `forceScheme('https')` to be configurable to allow local dev setups would be a good thing. My current workaround is a `compose.override.yml` with the following code, but it's not ideal :


# compose.override.yml
services:
  app:
    environment:
      APP_ENV: local

[badmike]

You're right, and it's worse than just your setup: this breaks every default Docker install. Sorry you walked into it.

What went wrong is that the implementation used APP_ENV to decide whether to generate https URLs, and that's not what APP_ENV means. The compose file pins APP_ENV=production, the installer writes APP_URL=http://localhost:8000, and the provider then forces https on anything production. So the page itself loads, every script and stylesheet points at an https port nobody is listening on.

Rather adding another flag for it, I made the scheme follow APP_URL. It already says how the instance is reached, so there's nothing new to configure: http stays http, and if you terminate TLS in front and put an HTTPS APP_URL in your .env, URLs still come out HTTPS even when X-Forwarded-Proto isn't trusted.

There's a second spot: The delivery API's revision redirect passed the environment straight into redirect()'s $secure argument, which is an override rather than a hint, so /contents was 301'ing you to https as well. Both are fixed in #27.

One heads-up on your workaround. APP_ENV=local also flips Laravel into strict model mode, so lazy loads and missing attributes start throwing instead of passing quietly. Fine while you're looking around, less fine once real content is in there. If you'd rather not carry that, ASSET_URL=http://localhost:8000 in the same override gets the UI back without touching APP_ENV, though it only covers assets. Redirects and mail links stay https until the fix ships.