logto docker file gets 404 on docker and Caddy

[Arazmalek]

Hello,
I have staging enviroment on docker which uses Caddy. after seeding the db and docker compose up, when I go to admin I get a 404 error. Here I share my Docker compose file + my Caddy file. I appreciate if you can let me know whats wrong.
docker-compose.yml:
`services:
logto:
image: ghcr.io/logto-io/logto:latest
container_name: logto_app
restart: always
expose:
- "3001"
- "3002"
environment:
TRUST_PROXY: ""
ENDPOINT: "https://auth-staging.met**"
ADMIN_ENDPOINT: "https://console-staging.met****"
DB_URL: "postgres://.amazonaws.com:5432/logto_staging?sslmode=no-verify"
REDIS_URL: "redis://logto_redis:6379"
NODE_TLS_REJECT_UNAUTHORIZED: "0"
COOKIE_DOMAIN: "met*"
COOKIE_SECURE: "true"
depends_on:
- redis

redis:
image: redis:alpine
container_name: logto_redis
restart: always
command: redis-server --save 60 1 --loglevel warning

caddy:
image: caddy:latest
container_name: logto_caddy
restart: always
ports:
- "80:80"
- "443:443"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile
- caddy_data:/data
- caddy_config:/config
depends_on:
- logto

volumes:
caddy_data:
caddy_config:`

Caddy file:
` GNU nano 7.2 Caddyfile *
auth-staging.met*** {
reverse_proxy logto:3001 {
header_up X-Forwarded-Proto https
}
}

console-staging.met*** {
reverse_proxy logto:3002 {
header_up X-Forwarded-Proto https
}
}
`

[wangsijie]

Hi @Arazmalek,

Your Docker Compose and Caddy configuration look mostly correct. Here are some things to check:

1. Check Logto container logs first

docker logs logto_app

This will tell you whether the 404 is coming from Logto itself or from somewhere else in the chain.

2. Verify database seeding completed successfully

Make sure you ran the seed command and it completed without errors:

docker run --rm \n  -e DB_URL="postgres://..." \n  ghcr.io/logto-io/logto:latest \n  npx @logto/cli db seed

A 404 on the admin console often indicates the initial data wasn't created properly.

3. Test connectivity inside the container

docker exec -it logto_app curl -I localhost:3002

If this returns 404, the issue is with Logto itself. If it returns 200, the issue is with Caddy/networking.

4. Enhance your Caddyfile headers

Try adding more forwarded headers:

console-staging.met*** {
    reverse_proxy logto:3002 {
        header_up X-Forwarded-Proto https
        header_up X-Forwarded-Host {host}
        header_up X-Real-IP {remote_host}
    }
}

5. Check if it's a Caddy 404 or Logto 404

Look at the response headers when you get the 404. A Caddy 404 will have Server: Caddy header, while a Logto 404 will have different headers.

Let us know what you find in the logs!

[Arazmalek]

Thanks for your answer. the problem is that I have checked the checklist that you said and it seems that everything is fine. it seems that inside docker everything is fine. in my redis it seems that the logto does not try to set session. this is the redis log which shows there is no session in it:

ubuntu@ip-15-0-**-**:~/logto_test$ docker exec -it logto_redis redis-cli monitor
OK
"GET" "default:sie:#"
"SET" "default:sie:#" "{\"tenantId\":\"default\",\"id\":\"default\",\"color\":{\"primaryColor\":\"#6139F6\",\"darkPrimaryColor\":\"#8768F8\",\"isDarkModeEnabled\":false},\"branding\":{\"logoUrl\":\"https://logto.io/logo.svg\",\"darkLogoUrl\":\"https://logto.io/logo-dark.svg\"},\"hideLogtoBranding\":false,\"languageInfo\":{\"autoDetect\":true,\"fallbackLanguage\":\"en\"},\"termsOfUseUrl\":null,\"privacyPolicyUrl\":null,\"agreeToTermsPolicy\":\"Automatic\",\"signIn\":{\"methods\":[{\"password\":true,\"identifier\":\"username\",\"verificationCode\":false,\"isPasswordPrimary\":true}]},\"signUp\":{\"verify\":false,\"password\":true,\"identifiers\":[\"username\"]},\"socialSignIn\":{},\"socialSignInConnectorTargets\":[],\"signInMode\":\"SignInAndRegister\",\"customCss\":null,\"customContent\":{},\"customUiAssets\":null,\"passwordPolicy\":{},\"mfa\":{\"policy\":\"UserControlled\",\"factors\":[]},\"singleSignOnEnabled\":false,\"supportEmail\":null,\"supportWebsiteUrl\":null,\"unknownSessionRedirectUrl\":null,\"captchaPolicy\":{},\"sentinelPolicy\":{},\"emailBlocklistPolicy\":{},\"forgotPasswordMethods\":[]}" "EX" "1800"
"GET" "default:tenant-cache-expires-at:#"
"GET" "default:sie:#"
"GET" "default:sie:#"
"GET" "default:is-development-tenant:#"
"GET" "default:custom-phrases-tags:#"
 "SET" "default:is-development-tenant:#" "false" "EX" "1800"
 "SET" "default:custom-phrases-tags:#" "[]" "EX" "1800"
 "GET" "default:custom-phrases:en"
 "GET" "default:tenant-cache-expires-at:#"
"GET" "default:sie:#"
"GET" "default:sie:#"
 "GET" "default:is-development-tenant:#"
-"GET" "default:custom-phrases-tags:#"
- "GET" "default:custom-phrases:en"

when I want to go to my admin console I am redirected to the normal endpoint(instead of admin) and I get a 404 error. when I inspect the page there is no session in response headers. I get a 302 on admin page and a 200 on the normal endpont when i am redirected too. in None of them I have session.
my docker compose is :

services:
  logto:
    image: ghcr.io/logto-io/logto
    container_name: logto_app
    restart: always
    expose:
      - "3001"
      - "3002"
    environment:
      TRUST_PROXY: "true"
      ENDPOINT: "https://logto-staging-user.met***"
      ADMIN_ENDPOINT: "https://logto-staging-admin.met***"
      DB_URL: "postgres://logt**"
      REDIS_URL: "redis://logto_redis:6379"
      NODE_TLS_REJECT_UNAUTHORIZED: "0"
      COOKIE_SECURE: "true"
      COOKIE_DOMAIN: "met***"
    depends_on:
      - redis

  redis:
    image: redis:alpine
    container_name: logto_redis
    restart: always
    command: redis-server --save 60 1 --loglevel warning

  caddy:
    image: caddy:latest
    container_name: logto_caddy
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config
    depends_on:
      - logto

volumes:
  caddy_data:
  caddy_config:

my Caddyfile:

logto-staging-user.m***{
    reverse_proxy logto:3001 {
        header_up X-Forwarded-Proto https
        header_up X-Forwarded-For {remote_host}
        header_up X-Forwarded-Host {host}
    }
}

logto-staging-admin.m***{
    reverse_proxy logto:3002 {
        header_up X-Forwarded-Proto https
        header_up X-Forwarded-For {remote_host}
        header_up X-Forwarded-Host {host}
    }
}

I am using the Formal image of logto. I have even tried with svhd/logto:latest image. It seems that logto itself is up and running, but I guess there is something run with sessions or small configuration which I am missing.
And also this is my log for Docker at the exact moment I try to go to admin console:

logto_app    | core     info Core app is running at http://localhost:3001/
logto_app    | core     info Core app is running at https://logto-staging-us***/
logto_app    | admin    info Admin app is running at http://localhost:3002/
logto_app    | admin    info Admin app is running at https://logto-staging-ad***/
logto_app    | CVcgqCfsdlzF42od   <-- GET /
logto_app    | tenant   info Init tenant: default Custom domain: undefined
logto_app    | CVcgqCfsdlzF42od   --> GET / 302 252ms 69b
logto_app    | KkP_ptmic1RT3vg6   <-- GET /unknown-session
logto_app    | cache    info Well-known cache hit for, default, sie, #
logto_app    | cache    info Well-known cache hit for, default, sie, #
logto_app    | KkP_ptmic1RT3vg6   --> GET /unknown-session 200 58ms 6.42kb
logto_app    | mkZMEzGJORY_bw8G   <-- GET /favicon.ico
logto_app    | cache    info Well-known cache hit for, default, sie, #
logto_app    | cache    info Well-known cache hit for, default, sie, #
logto_app    | cache    info Well-known cache hit for, default, is-development-tenant, #
logto_app    | cache    info Well-known cache hit for, default, custom-phrases-tags, #
logto_app    | mkZMEzGJORY_bw8G   --> GET /favicon.ico 200 27ms 6.42kb

Thanks for your time in advance

[wangsijie]

Sounds like a Redis connection issue - can you double check your REDIS_URL env var and make sure Logto can actually reach Redis from inside the container?

[Arazmalek]

in fact since we
"SET" "default:sie:#" "{\"tenantId\":\"default\"...
it seems the redis is fine. I even tried from logto container, it can communicated well. or there is something with logto_config table which is filled during seeding(I have no error during seeding), or i guess it must be related to to caddy. I dont know if you can see anything really suspicious on my configurations on docker or caddy

[Arazmalek]

I have aslso mention on my docker log I have these:

logto_app    | cache    info Connected to Redis
logto_app    | core     info Core app is running at http://localhost:3001/
logto_app    | core     info Core app is running at https://logto-staging-user.m***i/
logto_app    | admin    info Admin app is running at http://localhost:3002/
logto_app    | admin    info Admin app is running at https://logto-staging-admin.me***/

it seems it's running on local and https at the same time. also when i curl it seems the issuer is https and autorization_endpoint is http:

curl -s https://logto-staging-user.me***/oidc/.well-known/openid-configuration
{"authorization_endpoint":"http://logto-staging-user.me***/oidc/auth","claims_parameter_supported":false,"claims_supported":["sub","name","family_name","given_name","middle_name","nickname","preferred_username","profile","picture","website","gender","birthdate","zoneinfo","locale","updated_at","username","created_at","email","email_verified","phone_number","phone_number_verified","address","custom_data","identities","sso_identities","roles","organizations","organization_data","organization_roles","sid","auth_time","iss"],"code_challenge_methods_supported":["S256"],"end_session_endpoint":"http://logto-staging-user.m***oidc/session/end","grant_types_supported":["implicit","authorization_code","refresh_token","client_credentials","urn:ietf:params:oauth:grant-type:token-exchange"],"issuer":"https://logto-staging-user.m***oidc","jwks_uri":"http://logto-staging-user.m***oidc/jwks","authorization_response_iss_parameter_supported":true,"response_modes_supported":["form_post","fragment","query"],"response_types_supported":["code id_token","code","id_token","none"],"scopes_supported":["openid","offline_access","profile","email","phone","address","custom_data","identities","roles","urn:logto:scope:organizations","urn:logto:scope:organization_roles"],"subject_types_supported":["public"],"token_endpoint_auth_methods_supported":["client_secret_basic","client_secret_jwt","client_secret_post","private_key_jwt","none"],"token_endpoint_auth_signing_alg_values_supported":["HS256","RS256","PS256","ES256","EdDSA"],"token_endpoint":"http://logto-staging-user.m***/oidc/token","id_token_signing_alg_values_supported":["ES384"],"pushed_authorization_request_endpoint":"http://logto-staging-user.m***/oidc/request","request_parameter_supported":false,"request_uri_parameter_supported":false,"userinfo_endpoint":"http://logto-staging-user.m***/oidc/me","introspection_endpoint":"http://logto-staging-user.m***oidc/token/introspection","revocation_endpoint":"http://logto-staging-user.m***/oidc/token/revocation","backchannel_logout_supported":true,"backchannel_logout_session_supported":true,"claim_types_supported":["normal"]}

issuer https and authorization_endpoint http

[Arazmalek]

Just to let anybody which may have the same problem, I solved it by adding this line to my logto container:

entrypoint: ["sh", "-c", "npm run cli db seed -- --swe && npm start"]

and thanks to wang for participating and helping me