2FA error "An error occurred while verifying 2FA code"

[sylvaindeloux]

Hi

I can't access my Dokploy instance because of 2FA (504 error on /api/auth/two-factor/verify-totp call).
I tried the procedure described on #1337 but I don't have an auth table:

dokploy=# SELECT email, "is2FAEnabled" FROM auth;
ERROR:  relation "auth" does not exist

I'm on 0.28.8.

How can I disable 2FA?

Thanks

[dosubot[bot]]

Hi @sylvaindeloux! I'm Dosu and I’m helping the dokploy team.

This is a known issue caused by changes to the BETTER_AUTH_SECRET in recent Dokploy versions. The database schema has changed - there's no longer an auth table. Instead, 2FA data is stored in the two_factor and user tables.

Option A: Restore the original secret (try this first)

Set the BETTER_AUTH_SECRET environment variable to the original default value:

BETTER_AUTH_SECRET=better-auth-secret-123456789

Then restart Dokploy. This should allow your existing 2FA to work again.

Option B: Reset 2FA in the database

If that doesn't work, you can disable 2FA directly:

-- Find your user ID first
SELECT id, email FROM "user";

-- Delete 2FA records for your user
DELETE FROM two_factor WHERE "userId" = '<your_user_id>';

-- Disable 2FA flag
UPDATE "user" SET two_factor_enabled = false WHERE id = '<your_user_id>';

After this, you should be able to log in without 2FA and can re-enable it if desired.

See this issue for more details on the root cause.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[sylvaindeloux]

[dosubot[bot]]

The login issue after resetting 2FA is likely still related to the BETTER_AUTH_SECRET mismatch. Even after disabling 2FA, other encrypted authentication data may be affected.

Try setting the original auth secret:

Add this environment variable to your Dokploy container:

BETTER_AUTH_SECRET=better-auth-secret-123456789

Then restart Dokploy.

To see the actual error, check the logs:

docker service logs dokploy

This should show you the specific error causing the login failure.

Also note: about your SELECT * FROM user; result showing just "dokploy" — that's actually showing the PostgreSQL role name, not the table contents. The table name user is a reserved word in PostgreSQL. Try:

SELECT * FROM "user";

(with quotes) to see the actual user records.

There's also a known bug in v0.28.8 with authentication after upgrades due to a missing database migration. If setting the auth secret doesn't help, you might need to roll back to v0.28.6 temporarily.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[sylvaindeloux]

[dosubot[bot]]

Migrations run automatically on startup, but they can fail silently on Docker Swarm, which could explain your persistent login issues.

Check if migrations completed:

docker service logs dokploy

Look for "Migration complete" or any migration error messages.

Run migrations manually:

# Get the container ID
docker ps

# Run migrations inside the container
docker exec -it <container-id> bash -c "pnpm run migration:run"

If migrations are failing to run, try restarting the service (this often fixes timing issues where Dokploy starts before Postgres is ready):

docker service scale dokploy=0
docker service scale dokploy=1

Also, can you share the error from docker service logs dokploy? That would help identify whether this is a migration issue or something else with the auth system.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[sylvaindeloux]

[dosubot[bot]]

The pnpm run migration:run command is for development only — the production container uses compiled JavaScript, not TypeScript.

To run migrations manually in production:

docker exec -it <container-id> node -r dotenv/config dist/migration.mjs

Migrations should run automatically at startup, so if they didn't complete, you can also just restart the service:

docker service scale dokploy=0
docker service scale dokploy=1

That said, there's a known issue in v0.28.6+ where migrations may complete but then Drizzle ORM has connection timeout issues. If running migrations manually still doesn't fix your login problem, check the logs after running the migration command to see if there are any errors.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}