Unable to login after upgrade to 1.9.5

I had v1.9.0 installed on a VPS without a web server installed, I followed the instructions as per the upgrade guide with the added --migrate=true arg as there is no web server on the VPS to run the installation URL provided during an normal install/upgrade. All wen twell, the docker compose and .env were backed up and new args were added, I ran the upgrade command and stepped through the questions, set no to assistant and all others came from the .env file, secrets etc are unchanged. All green. I ran the migrate command, no issues in the output.

Since completing I have been unable to login with the console, 404 Not Found Error for Login, register and reset password

Console outputs POST https://..***/v1/account/sessions/email 404 (Not Found)

There is no error output in the logs, with a 200 response from /v1/health/version in the http.request.

Running docker ps --no-trunc I see all looks good EXCEPT for the appwrite container: appwrite/appwrite:1.9.5 - "docker-php-entrypoint php app/http.php" - 25 minutes ago - Up 25 minutes (unhealthy) - 80/tcp - appwrite

Where the executor uses the same args but is healthy. openruntimes/executor:0.25.1 - "docker-php-entrypoint php app/http.php" - 25 minutes ago - Up 25 minutes (healthy) - 80/tcp - exc1

Any ideas before I wipe the VPS and start again?

I can help. This usually happens when the Appwrite container upgrade didn’t complete properly or the reverse proxy/API routing is broken after migration, especially since the appwrite container is showing unhealthy and /v1/account/sessions/email is returning 404. Did you check the logs specifically for the appwrite and traefik/nginx containers, and can you confirm whether /v1/account endpoints respond locally from inside the VPS?

Hi Albert, I did look at container logs and nothing shows an error in appwrite logs and traefik logs are empty, appwrite-console does show normal load of page but no logs when clicking Sign-In etc. The VPS cannot connect locally either, 404 error still.

Running docker inspect appwrite in the Health->Status->Log section I see this

Running Appwrite Doctor for version 1.9.5 ...

[Settings] 🟢 Hostname is valid (###) 🟢 CNAME record target is valid (###) 🟢 A record target is valid (127.0.0.1) 🟢 AAAA record target is valid (::1) 🟢 Using a unique secret key for encryption 🟢 App environment is set for production 🟢 Abuse protection is enabled 🟢 Console access limits are enabled 🔴 HTTPS force option is disabled 🔴 HTTPS force option is disabled for function/site domains 🔴 Logging adapter is misconfigured

[Connectivity] 🔴 Console.DB.(console)...........................disconnected 🔴 Projects.DB.(database_db_main).................disconnected 🟢 Cache(cache_redis_main)...........................connected

Warning: foreach() argument must be of type array|object, null given in /usr/src/code/src/Appwrite/Platform/Tasks/Doctor.php on line 179 🟢 PubSub(pubsub)....................................connected

small mention regarding the Doctor, the DB entries are broken and shows disconnected anyways (you should check that part manually in the logs, and iirc the API container just don't start with no db connection)

also could you share the unhealthy container logs ?

also you said "Where the executor uses the same args but is healthy." can you clarify ? is it same env ? same conf ? same command ?

That helps a lot the big issue is the database connections showing as disconnected. That’s usually why the auth endpoints return 404 even though the containers themselves look “up.” It can happen after migration if the DB host/network/env values didn’t carry over correctly or if Docker volumes/networks got recreated differently during upgrade. I’ve dealt with this kind of Appwrite upgrade issue before. Send me a DM and I can help you trace the exact service causing it before you wipe the VPS.

the Doctor is broken and always shows disconnected for the DB.

it's the case for my Doctor result even tho the app work fine, it was already the case in 1.9.0

Albert, I will message tomorrow, thanks for the offer of help, nothing of value on the server but if there is something about the upgrade would be better its found.

Ibaraki, I will check tomorrow about the DB logs, as for the unhealthy container logs, in the first message I pasted two different lines from docker ps --no-trunc and they both use docker-php-entrypoint php app/http.php, where one is unhealthy but the other is healthy.

Thanks for the tip on the Doctor being broken.

Without helpful responses from the instance, just 404 Not Found error with no logs, I wiped the server and started again.

oh wait, i think i know

add this healthcheck to the appwrite compose service :

services:
  appwrite:
    healthcheck:
      test:
        - CMD-SHELL
        - 'curl -fsS -o /dev/null -H "Host: $${_APP_DOMAIN:-localhost}" http://localhost/v1/health/version'
      interval: 5s
      timeout: 5s
      retries: 12
      start_period: 120s

from this thread that i helped recently : https://discord.com/channels/564160730845151244/1524733765631610980

iirc, the reason is that since the healthcheck is broken, AND IS USED AS THE DOCKER HEALTHCHECK, the appwrite container just always fails because the doctor is broken

as a workaround, you curl the API to see if it's alive

Thanks Ibaraki but I had already wiped the server. I am now struggling to install a new instance, currently MONGO_DB variables are not being passed into the entrypoint in the docker-compose.yml downloaded from the appwrite Docs pages!!

oh ok, since i was kinda waiting for your reply i didn't added new messages.

Regarding the envs, there is no envs containing MONGO_DB it's :

_APP_DB_ADAPTER=mongodb
_APP_DB_HOST=mongodb
_APP_DB_PORT=27017
_APP_DB_SCHEMA=appwrite
_APP_DB_USER=user
_APP_DB_PASS=password
_APP_DB_ROOT_PASS=rootsecretpassword

as shown in the .env file from the Docs pages

and if you wonder, thoses envs are passed both to appwrite containers and the included mongodb with thoses mapping :

      - MONGO_INITDB_ROOT_USERNAME=root
      - MONGO_INITDB_ROOT_PASSWORD=${_APP_DB_ROOT_PASS}
      - MONGO_INITDB_DATABASE=${_APP_DB_SCHEMA}
      - MONGO_INITDB_USERNAME=${_APP_DB_USER}
      - MONGO_INITDB_PASSWORD=${_APP_DB_PASS}

where the ${...} use the value from the .env file

you might also want to use docker compose --env-file .env up to be sure the envs are used to validate the compose as well as using it inside the containers

Sorry I should have been clearer, in the entrypoint: script for mongodb in the docker-compose.yml, none of the variables are being passed in, docker compose config shows the environment is OK but not in the entrypoint script, also the KEYFILE_PATH and INIT_FLAG are also not found and the output says using an empty string, I have since got it to work by manually entering those two vars directly and using the .env name in the entrypoint script.

oh ye the keyfile, since i'm using mariadb in prod i can't really help, but iirc there was similar (or even maybe the exact same) issue in the threads