Is there an existing issue for this?
Current behavior
Hello!
I'm running Plane Community Edition locally via the official docker-compose.yml (cloned straight from the GitHub self-hosting repo, no Docker Swarm / Portainer). After the very first startup, the instance never completes initial setup.
Symptoms:
On http://localhost/, instead of the "Let's secure your instance" screen (to create the first admin), it immediately shows:
No authentication methods available. Please contact your administrator to enable authentication for your instance.
On http://localhost/god-mode/ — infinite loading (spinning logo), the setup screen never appears at all.
In the browser console and in the api container logs, there are consistent 401 Unauthorized responses for:
GET /api/instances/admins/me/
GET /api/instances/admins/
GET /api/users/me/
What I've already checked and ruled out:
GET /api/instances/ returns 200 OK with body: {"is_activated": false, "is_setup_done": false} (this by itself is expected for an unconfigured instance — the issue is that the frontend doesn't offer the setup flow at all).
The instance_configurations table in the database is empty (0 rows) and stays empty even after:
a targeted docker compose restart worker beat-worker api;
a full docker compose down && docker compose up -d (recreating all containers from scratch).
The message queue (plane-mq) is healthy and reachable — not a startup-order issue.
Migrations are fully applied, no errors:
Operations to perform: Apply all migrations: auth, contenttypes, db, django_celery_beat, license, sessions
Running migrations: No migrations to apply.
Volumes are intact and non-empty: plane_pgdata, plane_rabbitmq_data, plane_redisdata, plane_uploads — so the database wasn't silently lost/recreated.
WEB_URL, ADMIN_BASE_URL, API_BASE_URL, CORS_ALLOWED_ORIGINS are not set in .env (defaults are used) — so there's no mismatch between the frontend and API addresses; everything runs on http://localhost by default.
MACHINE_SIGNATURE is not applicable — that variable is for Swarm/Portainer deployments; I'm on a plain Docker Compose setup from the GitHub repo, and there's no plane.env file in the project.
Per Plane's docs, password login should be enabled automatically when SMTP isn't configured (and it isn't) — but in practice no authentication method appears at all.
Environment:
Install method: Docker Compose (GitHub self-hosting repo)
Services in docker compose ps: web, admin, space, api, bgworker (worker), beatworker (beat-worker), plane-migrator, plane-db, plane-mq, plane-redis, plane-minio, plane-proxy
Client OS: macOS (Docker Desktop)
Questions for the team/community:
What is supposed to populate the instance_configurations table on first boot — a migration, a one-off management command, or a signal handler triggered by the first API request? I expected "No migrations to apply" to mean full readiness, but the data was never created.
Is there a known bug where the "Let's secure your instance" screen is skipped, showing "No authentication methods available" directly instead (bypassing the first-admin creation step)?
Is there a safe way to manually initialize the instance's initial configuration (a management command/script), without risking the integrity of the licensing data?
Could the /god-mode/ page hanging on the logo specifically point to a separate issue (e.g., the admin app failing to reach the API), unrelated to the empty configuration table?
Happy to attach further logs (api, worker, beat-worker, migrator), my .env contents (secrets redacted), and the output of TABLE instances; if that helps diagnose this.
Thanks for the help!
Steps to reproduce
- Clone the official Plane self-hosting repository and use the provided docker-compose.yml as-is (no Docker Swarm / Portainer, no custom .env overrides for WEB_URL / ADMIN_BASE_URL / API_BASE_URL / CORS_ALLOWED_ORIGINS — all left at defaults).
- Run
docker compose up -d to start the full stack (services: web, admin, space, api, bgworker (worker), beatworker (beat-worker), plane-migrator, plane-db, plane-mq, plane-redis, plane-minio, plane-proxy).
- Wait for all containers to report "Started"/healthy status (confirmed via
docker compose ps; plane-mq, plane-db, plane-redis all healthy).
- Check that migrations completed:
docker compose logs migrator shows:
"Operations to perform: Apply all migrations: auth, contenttypes, db, django_celery_beat, license, sessions"
"Running migrations: No migrations to apply."
- Open http://localhost/ in a fresh/private browser window.
- Instead of the expected "Let's secure your instance" first-admin setup screen, the app immediately shows:
"No authentication methods available. Please contact your administrator to enable authentication for your instance."
- Navigate to http://localhost/god-mode/ instead — the page hangs indefinitely on the loading logo/spinner and never renders the setup screen.
- Open browser DevTools → Console/Network on /god-mode/: repeated 401 Unauthorized responses on:
- GET /api/instances/admins/me/
- GET /api/instances/admins/
- GET /api/users/me/
- Query the API directly:
curl -s http://localhost/api/instances/ returns 200 OK with body:
{"is_activated": false, "is_setup_done": false}
(expected/normal for a fresh instance — but the frontend does not offer the setup flow despite this).
- Inspect the database directly:
docker compose exec -T plane-db psql -U plane -d plane -c "TABLE instance_configurations;" returns 0 rows — the configuration table is never populated.
- Attempt recovery steps, all unsuccessful:
a. Targeted restart: docker compose restart worker beat-worker api → instance_configurations still empty.
b. Full stack recreation: docker compose down && docker compose up -d → instance_configurations still empty.
c. Verified message queue (plane-mq) healthy throughout — not a startup-order issue.
d. Verified plane_pgdata, plane_rabbitmq_data, plane_redisdata, plane_uploads volumes are intact and non-empty — data was not silently lost.
e. Checked for MACHINE_SIGNATURE env var — not applicable/not present, since this is a plain Docker Compose (GitHub repo) install, not Swarm/Portainer.
Expected result: On first boot, the instance_configurations table should be populated and http://localhost/ (or /god-mode/) should present the "Let's secure your instance" screen to create the first admin account.
Actual result: instance_configurations remains empty indefinitely, no authentication method is ever enabled, and /god-mode/ hangs on load instead of showing the setup screen.
Environment
Production
Browser
None
Variant
Self-hosted
Version
v0.24.1
Is there an existing issue for this?
Current behavior
Hello!
I'm running Plane Community Edition locally via the official docker-compose.yml (cloned straight from the GitHub self-hosting repo, no Docker Swarm / Portainer). After the very first startup, the instance never completes initial setup.
Symptoms:
On http://localhost/, instead of the "Let's secure your instance" screen (to create the first admin), it immediately shows:
No authentication methods available. Please contact your administrator to enable authentication for your instance.
On http://localhost/god-mode/ — infinite loading (spinning logo), the setup screen never appears at all.
In the browser console and in the api container logs, there are consistent 401 Unauthorized responses for:
GET /api/instances/admins/me/
GET /api/instances/admins/
GET /api/users/me/
What I've already checked and ruled out:
GET /api/instances/ returns 200 OK with body: {"is_activated": false, "is_setup_done": false} (this by itself is expected for an unconfigured instance — the issue is that the frontend doesn't offer the setup flow at all).
The instance_configurations table in the database is empty (0 rows) and stays empty even after:
a targeted docker compose restart worker beat-worker api;
a full docker compose down && docker compose up -d (recreating all containers from scratch).
The message queue (plane-mq) is healthy and reachable — not a startup-order issue.
Migrations are fully applied, no errors:
Operations to perform: Apply all migrations: auth, contenttypes, db, django_celery_beat, license, sessions
Running migrations: No migrations to apply.
Volumes are intact and non-empty: plane_pgdata, plane_rabbitmq_data, plane_redisdata, plane_uploads — so the database wasn't silently lost/recreated.
WEB_URL, ADMIN_BASE_URL, API_BASE_URL, CORS_ALLOWED_ORIGINS are not set in .env (defaults are used) — so there's no mismatch between the frontend and API addresses; everything runs on http://localhost by default.
MACHINE_SIGNATURE is not applicable — that variable is for Swarm/Portainer deployments; I'm on a plain Docker Compose setup from the GitHub repo, and there's no plane.env file in the project.
Per Plane's docs, password login should be enabled automatically when SMTP isn't configured (and it isn't) — but in practice no authentication method appears at all.
Environment:
Install method: Docker Compose (GitHub self-hosting repo)
Services in docker compose ps: web, admin, space, api, bgworker (worker), beatworker (beat-worker), plane-migrator, plane-db, plane-mq, plane-redis, plane-minio, plane-proxy
Client OS: macOS (Docker Desktop)
Questions for the team/community:
What is supposed to populate the instance_configurations table on first boot — a migration, a one-off management command, or a signal handler triggered by the first API request? I expected "No migrations to apply" to mean full readiness, but the data was never created.
Is there a known bug where the "Let's secure your instance" screen is skipped, showing "No authentication methods available" directly instead (bypassing the first-admin creation step)?
Is there a safe way to manually initialize the instance's initial configuration (a management command/script), without risking the integrity of the licensing data?
Could the /god-mode/ page hanging on the logo specifically point to a separate issue (e.g., the admin app failing to reach the API), unrelated to the empty configuration table?
Happy to attach further logs (api, worker, beat-worker, migrator), my .env contents (secrets redacted), and the output of TABLE instances; if that helps diagnose this.
Thanks for the help!
Steps to reproduce
docker compose up -dto start the full stack (services: web, admin, space, api, bgworker (worker), beatworker (beat-worker), plane-migrator, plane-db, plane-mq, plane-redis, plane-minio, plane-proxy).docker compose ps; plane-mq, plane-db, plane-redis all healthy).docker compose logs migratorshows:"Operations to perform: Apply all migrations: auth, contenttypes, db, django_celery_beat, license, sessions"
"Running migrations: No migrations to apply."
"No authentication methods available. Please contact your administrator to enable authentication for your instance."
curl -s http://localhost/api/instances/returns 200 OK with body:{"is_activated": false, "is_setup_done": false}
(expected/normal for a fresh instance — but the frontend does not offer the setup flow despite this).
docker compose exec -T plane-db psql -U plane -d plane -c "TABLE instance_configurations;"returns 0 rows — the configuration table is never populated.a. Targeted restart:
docker compose restart worker beat-worker api→ instance_configurations still empty.b. Full stack recreation:
docker compose down && docker compose up -d→ instance_configurations still empty.c. Verified message queue (plane-mq) healthy throughout — not a startup-order issue.
d. Verified
plane_pgdata,plane_rabbitmq_data,plane_redisdata,plane_uploadsvolumes are intact and non-empty — data was not silently lost.e. Checked for MACHINE_SIGNATURE env var — not applicable/not present, since this is a plain Docker Compose (GitHub repo) install, not Swarm/Portainer.
Expected result: On first boot, the instance_configurations table should be populated and http://localhost/ (or /god-mode/) should present the "Let's secure your instance" screen to create the first admin account.
Actual result: instance_configurations remains empty indefinitely, no authentication method is ever enabled, and /god-mode/ hangs on load instead of showing the setup screen.
Environment
Production
Browser
None
Variant
Self-hosted
Version
v0.24.1