Screen - No authentication methods available (On Pod restart)

Support
, ,
1

Hello,

We’re running Plane on a GKE Autopilot Kubernetes cluster. Because Autopilot regularly restarts nodes (and therefore pods) for maintenance and upgrades, our Plane pods are restarted roughly once a week. After these restarts, the application shows a “No authentication methods available” screen.

At this point, the /god-mode/ endpoint is still accessible, and we can consistently recover by manually restarting the plane-app-silo-wl pod followed by the plane-app-api-wl pod. Once those are restarted, we also have to clear the browser cache (otherwise the “No authentication methods available” screen persists), after which everything works normally.

We’d like to avoid this manual recovery sequence (extra pod restarts and browser cache clearing), as it is tedious and confusing for team members. Are there any known issues, configuration recommendations, or fixes to prevent this behavior after pod restarts on Kubernetes?

Screenshot 2026-03-06 at 11.31.26 am
Screenshot 2026-03-06 at 11.31.26 am1906×963 25.3 KB

2

Do you see any errors in the silo and api pod logs?

3

No there are not errors in either of the pods. Which is the strange part.

There is an error in the silo pod:

plane-app-silo [MISSING_ENV_FILE] missing .env file (/app/.env) plane-app-silo [MISSING_ENV_FILE] error code: `[MISSING_ENV_FILE]` · Issue #484 · dotenvx/dotenvx · GitHub │
plane-app-silo [dotenvx@1.51.1] injecting env (0)

But i think this is standard since it is running in k8 and using secrets rather than a self hosted instance.
Also this same warning/error appears even when it is working, which is why i’d call it a distractor.

4

Could you please check if **api/instances**endpoint is working when you open the web application? If it is, could you please share the response after removing any PI from it?

5

I’ve been trying to keep the system in its broken state for debugging, but it somehow started working again without the above listed manual recovery steps. It’s been about four days since the last pod restarts due to a recent Kubernetes maintenance/upgrade.

When it’s in the “No authentication methods available” screen state, the api/instances endpoint usually stops working and returns an HTML response instead of JSON. I would share the HTML output, but at the moment it’s working normally again and returning a proper JSON response.

Also, when the “No authentication methods available” screen appears, the API logs show this — not sure if it’s relevant:

[2026-03-12 06:52:41 +0000] [11621] [INFO] Booting worker with pid: 11621
/usr/local/lib/python3.12/site-packages/django/core/handlers/base.py:61: UserWarning: No directory at: /code/plane/static-assets/collected-static/
  mw_instance = middleware(adapted_handler)

Actually, I was just able to reproduce a similar state by restarting the API server and trying to access the frontend before the pod was fully ready(infact it’s persisting even after the pod is fully ready and browser cache cleared). This triggered the same “No authentication methods available” screen, and the api/instances endpoint again returned HTML instead of JSON.

Here’s a sample of the HTML response from the endpoint when in the broken state:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charSet="utf-8"/>
        <meta name="viewport" content="width=device-width, initial-scale=1"/>
        <meta name="theme-color" content="#fff"/>
        <meta name="application-name" content="Plane"/>
        <meta name="apple-mobile-web-app-capable" content="yes"/>
        <meta name="apple-mobile-web-app-status-bar-style" content="default"/>
        <meta name="apple-mobile-web-app-title" content="Plane | Simple, extensible, open-source project management tool."/>
        <meta name="format-detection" content="telephone=no"/>
        <meta name="mobile-web-app-capable" content="yes"/>
        <title>Plane | Simple, extensible, open-source project management tool.</title>
        <meta name="description" content="Open-source project management tool to manage work items, cycles, and product roadmaps easily"/>
        <meta property="og:title" content="Plane | Simple, extensible, open-source project management tool."/>
        <meta property="og:description" content="Open-source project management tool to manage work items, cycles, and product roadmaps easily"/>
 ...
 ...

And here is a screenshot of the network tab:

Screenshot 2026-03-12 at 5.32.34 am
Screenshot 2026-03-12 at 5.32.34 am914×818 69.8 KB

I also just noticed the Response Headers.Server is nginx/1.29.4 though we are using traefik(this fact might be irrelevant as everything works fine when not in this state, just wanted to mention)

The api server does not append any logs when refreshing the frontend page in this state. Current api logs:

Waiting for database...
Database available!
No migrations Pending. Starting processes ...
Instance already registered
ENABLE_SIGNUP configuration already exists
ENABLE_EMAIL_PASSWORD configuration already exists
ENABLE_MAGIC_LINK_LOGIN configuration already exists
DISABLE_WORKSPACE_CREATION configuration already exists
GOOGLE_CLIENT_ID configuration already exists
GOOGLE_CLIENT_SECRET configuration already exists
ENABLE_GOOGLE_SYNC configuration already exists
GITHUB_CLIENT_ID configuration already exists
GITHUB_CLIENT_SECRET configuration already exists
GITHUB_ORGANIZATION_ID configuration already exists
ENABLE_GITHUB_SYNC configuration already exists
GITLAB_HOST configuration already exists
GITLAB_CLIENT_ID configuration already exists
GITLAB_CLIENT_SECRET configuration already exists
ENABLE_GITLAB_SYNC configuration already exists
IS_GITEA_ENABLED configuration already exists
GITEA_HOST configuration already exists
GITEA_CLIENT_ID configuration already exists
GITEA_CLIENT_SECRET configuration already exists
ENABLE_GITEA_SYNC configuration already exists
ENABLE_SMTP configuration already exists
EMAIL_HOST configuration already exists
EMAIL_HOST_USER configuration already exists
EMAIL_HOST_PASSWORD configuration already exists
EMAIL_PORT configuration already exists
EMAIL_FROM configuration already exists
EMAIL_USE_TLS configuration already exists
EMAIL_USE_SSL configuration already exists
LLM_API_KEY configuration already exists
LLM_PROVIDER configuration already exists
LLM_MODEL configuration already exists
GPT_ENGINE configuration already exists
UNSPLASH_ACCESS_KEY configuration already exists
IS_INTERCOM_ENABLED configuration already exists
INTERCOM_APP_ID configuration already exists
OIDC_CLIENT_ID configuration already exists
OIDC_CLIENT_SECRET configuration already exists
OIDC_TOKEN_URL configuration already exists
OIDC_USERINFO_URL configuration already exists
OIDC_AUTHORIZE_URL configuration already exists
IS_OIDC_ENABLED configuration already exists
OIDC_LOGOUT_URL configuration already exists
OIDC_PROVIDER_NAME configuration already exists
ENABLE_OIDC_IDP_SYNC configuration already exists
SAML_ENTITY_ID configuration already exists
SAML_SSO_URL configuration already exists
SAML_CERTIFICATE configuration already exists
SAML_LOGOUT_URL configuration already exists
IS_SAML_ENABLED configuration already exists
SAML_PROVIDER_NAME configuration already exists
ENABLE_SAML_IDP_SYNC configuration already exists
SAML_DISABLE_REQUESTED_AUTHN_CONTEXT configuration already exists
IS_LDAP_ENABLED configuration already exists
LDAP_SERVER_URI configuration already exists
LDAP_BIND_DN configuration already exists
LDAP_BIND_PASSWORD configuration already exists
LDAP_USER_SEARCH_BASE configuration already exists
LDAP_USER_SEARCH_FILTER configuration already exists
LDAP_USER_ATTRIBUTES configuration already exists
LDAP_PROVIDER_NAME configuration already exists
IS_GOOGLE_ENABLED configuration already exists
IS_GITHUB_ENABLED configuration already exists
IS_GITLAB_ENABLED configuration already exists
IS_GITEA_ENABLED configuration already exists
Checking bucket...
Bucket 'uploads' exists.
Cache Cleared
Successfully triggered the sync license on startup task
[2026-03-12 10:24:55 +0000] [1] [INFO] Starting gunicorn 23.0.0
[2026-03-12 10:24:55 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1)
[2026-03-12 10:24:55 +0000] [1] [INFO] Using worker: uvicorn.workers.UvicornWorker
[2026-03-12 10:24:55 +0000] [194] [INFO] Booting worker with pid: 194
/usr/local/lib/python3.12/site-packages/django/core/handlers/base.py:61: UserWarning: No directory at: /code/plane/static-assets/collected-static/
  mw_instance = middleware(adapted_handler)
6

Thanks for sharing the logs, Henry. Based on these logs, it looks like the issue is mainly due to incorrect messaging from our side.

When the API containers restart, the web application should display a maintenance mode message. However, according to your api/instances response, when the API container is down, all /api endpoints appear to route back to the web container, which returns an HTML document instead.

Right now, we only check the status of the instances API response, not the actual response data. Because of this, the application doesn’t detect that the response is invalid and ends up showing the wrong message.

We’ll update this logic to also validate the response data so that the correct maintenance message is shown when the API containers are unavailable.

7

That sounds great, thanks for the clarification!

I had one more question. Do you have any insights on caching behavior for that response? It might already be addressed by your planned update, but currently, the HTML response that triggers the “No authentication methods available” screen seems to get cached for the api/instances endpoint.

As a result, even after the application comes back online, users who accessed the page during maintenance need to manually clear their browser cache to recover.

Ideally, both the api/instances/ and api/me/ endpoints wouldn’t cache responses in this broken state, so that once the pods are back online, the app makes fresh requests to the API server instead of using the cached HTML.