Feat/aws ecr registry support

[EphraimHaber]

• Add AWS ECR as a new registry type alongside existing cloud registries
• Implement ECR-specific authentication using AWS credentials instead of username/password
• Add conditional validation schemas that require different fields based on registry type:
  • ECR: registryUrl, awsAccessKeyId, awsSecretAccessKey, awsRegion
  • Regular: username, password
• Create executeECRLogin helper function for centralized ECR authentication logic
• Update both frontend and backend validation to use superRefine with field-specific error messages
• Fix apiCreateRegistry schema to make username/password optional for ECR registries
• Add proper shell escaping for security in all registry login commands

Backend changes:

• Update registry database schema to include AWS ECR fields
• Add getSafeECRLoginCommand and getSafeDockerLoginCommand helper functions
• Modify apiTestRegistry to handle ECR authentication flow
• Update registry services to use centralized login command generation

Frontend changes:

• Add ECR-specific form fields (AWS credentials, region)
• Implement conditional form validation matching backend logic
• Update registry creation/testing UI to handle ECR workflow

This enables users to connect to AWS ECR repositories using their AWS credentials while maintaining backward compatibility with existing Docker registries.

What is this PR about?

Please describe in a short paragraph what this PR is about.

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.

Issues related (if applicable)

closes #2040

Screenshots (if applicable)

Greptile Summary

This PR adds AWS ECR as a supported registry type in Dokploy, enabling users to authenticate with ECR repositories using AWS IAM credentials instead of username/password. The implementation uses the AWS SDK (@aws-sdk/client-ecr) for token acquisition, shells out to docker login --password-stdin for safe credential passing, adds conditional Zod validation on both the frontend and backend, and extends the database schema with three new nullable ECR-specific columns.

Key changes and highlights:

• getECRAuthToken / loginDockerToECR in packages/server/src/utils/aws/ecr.ts handle AWS SDK token fetching and Docker login with correct printf %s ... | docker login --password-stdin piping.
• getSafeRegistryLoginCommand / getSafeDockerLoginCommand in the registry schema centralize safe shell command generation, and have been correctly applied in testRegistry, testRegistryById, createRegistry, updateRegistry, and getRegistryCommands.
• Both apiCreateRegistry and apiTestRegistry use superRefine to enforce field-specific validation for ECR vs. non-ECR registries.
• The frontend correctly omits awsSecretAccessKey from update payloads when the field is left blank, preventing accidental credential erasure.
• Secrets (password, awsSecretAccessKey) are excluded from findRegistryById and findAllRegistryByOrganizationId results, protecting credentials from being leaked through API responses.
• Two minor issues remain: (1) the local pullImage path in docker/utils.ts still passes passwords via the -p flag (process-list visibility) rather than --password-stdin, inconsistent with the PR's stated security goal; (2) the ECR authconfig forwarded to dockerode's remoteDocker.pull is in the wrong format — it works in practice only because the docker login call caches credentials on the daemon first.

Confidence Score: 5/5

This PR is safe to merge; all remaining findings are P2 style or best-practice issues that do not block correctness in normal usage.

All previously raised P0/P1 concerns (ECR token split, unescaped credentials, missing validation, secret key overwrite on edit) have been resolved in the current code. The two remaining findings are P2: the pullImage path still uses -p (password in process list, not an injection vector), and the dockerode authconfig format for ECR is wrong but works in practice thanks to cached daemon credentials. Neither blocks the primary ECR registration and deploy flow.

packages/server/src/utils/docker/utils.ts — pullImage still uses -p and pullRemoteImage passes a malformed authconfig to dockerode for ECR pulls.

Comments Outside Diff (1)

1. packages/server/src/utils/providers/docker.ts, line 48-52 (link)

   Unescaped shell variables in non-ECR Docker login command

   The PR introduces getSafeDockerLoginCommand and getSafeRegistryLoginCommand for proper shell escaping, but the pre-existing non-ECR branch here still interpolates password, username, and registryUrl directly into a shell command string without any escaping. A credential containing ", $, or a backtick can break the command or enable injection. The new helper getSafeDockerLoginCommand (added in packages/server/src/db/schema/registry.ts) should be used here instead of the raw template literal, consistent with how all other login paths in this PR are now handled.

_{Reviews (3): Last reviewed commit: "re add my drizzle" | Re-trigger Greptile}

[EphraimHaber]

How to retrigger the auto CR after fixes?

[EphraimHaber]

can you check the pr again? all issues have beed addressed @greptileai

[EphraimHaber]

okay seems like someone with permissions is required for re trigger greptile. those were nice catches NGL

[EphraimHaber]

can you check the pr again? all issues have beed addressed @greptileai

[EphraimHaber]

@greptileai please review the pr again

[EphraimHaber]

@Siumauricio When u get a chance re trigger greptileai plz

[EphraimHaber]

AHA 5/5 let's gooo @Siumauricio