Describe the bug

On self-hosted (non-cloud) instances the password-reset flow can never complete. getServerSideProps in both apps/dokploy/pages/reset-password.tsx and apps/dokploy/pages/send-reset-password.tsx redirects to / when !IS_CLOUD, so the link from the reset email always lands on the login page.

The server side is not gated: emailAndPassword.enabled is true unconditionally and sendResetPassword actually sends the email (when SMTP env is configured). So the email goes out, but the page it points to is blocked — a dead end for every self-hosted user.

To Reproduce

1. Self-hosted instance (IS_CLOUD unset), SMTP_* env configured.
2. Trigger a password reset for an existing user (e.g. via /api/auth/request-password-reset, or the "Forgot password" form).
3. The email arrives with a link to /reset-password?token=....
4. Opening the link redirects to / (login). The password can never be reset.

Expected behavior

Self-hosted users can open the reset link and set a new password, the same as on cloud.

Cause

The if (!IS_CLOUD) { redirect -> "/" } guard in getServerSideProps of both pages. The token-based reset endpoint is already available on-prem.

Suggested fix

Drop the !IS_CLOUD guard on both pages (keeping the existing token guard on /reset-password). PR incoming.

Environment

• Dokploy: canary (self-hosted, Docker Swarm)