fix(auth): respect HTTPS when setting secure cookies on self-hosted

[hypertonny]

Summary

Fixes a critical authentication bug affecting all self-hosted Dokploy instances served over an HTTPS custom domain behind a TLS-terminating reverse proxy (Traefik, Cloudflare, Nginx).

Closes #5143
Related: #4709

---

Problem

When a self-hosted Dokploy instance is accessed via an HTTPS custom domain, every tRPC request returns 403 Forbidden, making the dashboard completely unusable over HTTPS.

Root Cause

In packages/server/src/lib/auth.ts, useSecureCookies and secure are hardcoded to false for all self-hosted deployments:

advanced: {
  useSecureCookies: false,   // ← hardcoded regardless of protocol
  defaultCookieAttributes: {
    secure: false,           // ← hardcoded regardless of protocol
  },
},

When a browser connects over HTTPS, it silently drops any cookie without the Secure attribute. Every tRPC request then has no valid session → 403 Forbidden. Accessing over http://<IP>:3000 works fine, making this hard to diagnose.

---

Fix

Introduce a SECURE_COOKIES environment variable operators can set when serving Dokploy over HTTPS:

advanced: {
  useSecureCookies: process.env.SECURE_COOKIES === "true",
  defaultCookieAttributes: {
    sameSite: "lax" as const,
    secure: process.env.SECURE_COOKIES === "true",
    httpOnly: true,
    path: "/",
  },
},

Add to docker-compose.yml:

services:
  dokploy:
    environment:
      SECURE_COOKIES: "true"

---

Impact

Scenario	Before	After
http://<IP>:3000	✅ Works	✅ Works
https://<domain> without env var	❌ 403	❌ Same (opt-in required)
https://<domain> + SECURE_COOKIES=true	❌ 403	✅ Fixed
Cloud deployments	✅ Works	✅ Works

Non-breaking change — existing deployments without the env var are unaffected.

---

Testing

Tested on a live self-hosted instance (Azure VPS, Traefik + Cloudflare, v0.30.2). Without fix: 403 on all tRPC routes over HTTPS. With SECURE_COOKIES=true: dashboard fully functional.

---

Checklist

• Branch based on canary
• Read CONTRIBUTING.md
• Tested on a live self-hosted instance
• Non-breaking change

Greptile Summary

This PR makes Better Auth’s secure-cookie behavior configurable for self-hosted deployments through SECURE_COOKIES.

• Applies the setting to both Better Auth’s secure-cookie mode and default cookie attributes.
• Preserves the existing non-secure default for self-hosted HTTP deployments.
• Does not add the new setting to checked-in operator-facing configuration or environment examples.

Confidence Score: 4/5

The PR appears safe to merge, with a non-blocking configuration-documentation gap that may prevent self-hosted operators from activating the fix.

The cookie configuration consistently applies the new boolean to both relevant Better Auth settings, but no checked-in operator-facing configuration advertises or supplies the required environment variable.

Files Needing Attention: packages/server/src/lib/auth.ts

_{Reviews (1): Last reviewed commit: "fix(auth): respect HTTPS when setting se..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[Copilot]

Pull request overview

This PR addresses self-hosted authentication failures when Dokploy is served over HTTPS behind a TLS-terminating reverse proxy by allowing operators to opt into Secure cookies via an environment variable.

Changes:

• Makes BetterAuth cookie security configurable for non-cloud deployments via SECURE_COOKIES.
• Sets defaultCookieAttributes.secure based on SECURE_COOKIES and tightens the sameSite literal typing.
• Adds inline guidance in auth.ts for self-hosted operators on when to enable Secure cookies.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[greptile-apps]

Secure-cookie setting is undiscoverable

SECURE_COOKIES is required to activate the HTTPS fix, but the new setting is absent from checked-in environment examples and deployment configuration. Operators following the existing self-hosted setup therefore retain non-secure cookies until they independently discover and add the variable.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!