[Gourav224]

What is this PR about?

Installs without BETTER_AUTH_SECRET encrypt env vars with a key derived from the hardcoded legacy secret. When you follow the startup warning and set a real secret, the key changes, and every existing env, buildArgs and buildSecrets value becomes undecryptable (#4833). It then fails silently: encryptedText returns the ciphertext, dotenv parses enc:v1:… to {}, and the service deploys with an empty environment while the deployment shows done.

Two small changes:

1. Decrypt-only fallback for the legacy key (packages/server/src/lib/encryption.ts). decryptValue also tries deriveKey(HARDCODED_LEGACY_SECRET) when it isn't already the primary key. This is the same pattern the code already uses when adopting ENCRYPTION_KEY. Encryption still always uses the primary key, so values re-encrypt with the real secret on their next write. The legacy secret is a published constant, so this exposes nothing new. The key is not added to exportEncryptionKeys() (backups).
2. Fail the deployment instead of deploying an empty environment (prepareEnvironmentVariables). If a service, project or environment env still starts with enc:v1:, it throws a clear error. The error lands in the deployment log, like the existing unresolved-vault-reference check. This covers any other key mismatch too, such as a restore under a different secret.

Rotating between two real secrets is still out of scope. That needs a re-encryption step, as migrate-auth-secret.ts does for 2FA, and is a bigger change.

Checklist

Before submitting this PR, please make sure that:

• You created a dedicated branch based on the canary branch.
• You have read the suggestions in the CONTRIBUTING.md file https://github.com/Dokploy/dokploy/blob/canary/CONTRIBUTING.md#pull-request
• You have tested this PR in your local instance. If you have not tested it yet, please do so before submitting. This helps avoid wasting maintainers' time reviewing code that has not been verified by you.

Testing (real AES-GCM, no crypto mocks):

• __test__/env/encryption.test.ts: a value encrypted on the legacy secret decrypts after BETTER_AUTH_SECRET is set; new writes use the new secret; the legacy key isn't exported; values from an unrelated earlier secret still fail.
• __test__/env/shared.test.ts: prepareEnvironmentVariables throws for encrypted service, project and environment env.
• Full vitest suite: 1294 passed. application.real.test.ts needs nixpacks and was excluded; it fails the same way on canary. tsc --noEmit for packages/server passes.

Issues related (if applicable)

closes #4833

This follows the approach proposed in the issue thread (#4834, closed by its author without being merged).

🤖 Generated with Claude Code

Confidence Score: 4/5

Fix the Docker Compose path before merging so unreadable service variables stop the deployment.

Summary

This PR keeps values encrypted with the legacy auth secret readable after a secret change.

• Values saved with the old default secret stay readable after the secret changes.
• Environment preparation stops when a saved value is still encrypted.

_{Reviews (1) · Last reviewed commit: "fix(encryption): keep env vars readable ..." · Reviewed by Greptile}

[greptile-apps]

Compose still drops saved variables

For Docker Compose deployments, getCreateEnvFileCommand adds APP_NAME and COMPOSE_PROJECT_NAME before compose.env. If the saved service variables cannot be decrypted, the resulting string no longer starts with enc:v1:, so this check misses it. With readable project and environment settings, dotenv drops the encrypted line and the deployment can report success without the saved service variables.

Check the original compose.env before adding generated variables, and add a test through getCreateEnvFileCommand.

Knowledge Base Used:

• Build and Compose workflows
• Deployment lifecycle

[Gourav224]

Right, fixed in 90ba1e2. The guard in prepareEnvironmentVariables now checks every line for enc:v1:, not just the start of the string. Ciphertext is base64 and always on its own line, so this covers compose's generated APP_NAME/COMPOSE_PROJECT_NAME prefix and any other caller that combines env text. I added tests for both the prefixed string and getCreateEnvFileCommand with an undecryptable compose.env.