feat: add optional dockerImage field to database schemas

[Siumauricio]

• Updated MariaDB, MongoDB, MySQL, PostgreSQL, and Redis schemas to include an optional dockerImage field for enhanced configuration flexibility.

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. 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.

Issues related (if applicable)

closes #3983

Screenshots (if applicable)

Greptile Summary

Adds an explicit dockerImage: z.string().optional() override in the .extend() block of all five database update schemas (apiUpdateMariaDB, apiUpdateMongo, apiUpdateMySql, apiUpdatePostgres, apiUpdateRedis). This removes the .default() value that was inherited from createSchema.partial(), preventing the default docker image tag from being silently applied during update operations when dockerImage is not included in the payload.

• Consistent one-line change applied identically across mariadb.ts, mongo.ts, mysql.ts, postgres.ts, and redis.ts
• Fixes the issue where updating a database service (e.g., changing command/args) could inadvertently reset the dockerImage to its schema default (e.g., "mariadb:6") instead of preserving the user's custom image
• The frontend (show-custom-command.tsx) always sends dockerImage in its update payload, so this is a defensive fix for API consumers that may omit it

Confidence Score: 5/5

• This PR is safe to merge — it's a minimal, well-targeted fix applied consistently across all five database schemas.
• Score of 5 reflects that the change is a single-line addition repeated identically across five files, with clear purpose (removing the default value from the update schema to prevent unintended overwrites). The pattern is consistent, the logic is correct, and the database column is NOT NULL so existing data is not at risk. No new dependencies, no schema migrations, and no behavioral changes for the primary frontend consumer which always sends dockerImage explicitly.
• No files require special attention

_{Last reviewed commit: bb521f3}

[dosubot]

Documentation Updates

1 document(s) were updated by changes in this PR:

README

View Changes

@@ -252,6 +252,24 @@
 - Results are ordered by creation date (descending)
 - Members only see services they have access to
 - Returns total count for pagination UI
+
+## Database Service Update Endpoints
+
+All database services support update operations with flexible configuration options. The following database services share a common update interface:
+- **postgres.update** (apiUpdatePostgres)
+- **mysql.update** (apiUpdateMySql)
+- **mariadb.update** (apiUpdateMariaDB)
+- **mongo.update** (apiUpdateMongo)
+- **redis.update** (apiUpdateRedis)
+
+**Common Parameters:**
+
+All database update endpoints accept their respective ID field (e.g., `postgresId`, `mysqlId`, `mariadbId`, `mongoId`, `redisId`) as a required parameter, along with optional configuration fields.
+
+**Optional Configuration:**
+- `dockerImage` (optional string) - Specifies a custom Docker image for the database service. This allows users to use specific versions or custom-built images instead of the default image for the database type. Available for all five database services (PostgreSQL, MySQL, MariaDB, MongoDB, and Redis).
+
+Additional service-specific parameters are available depending on the database type. The `dockerImage` field provides enhanced configuration flexibility for advanced use cases such as version pinning or using specialized database distributions.
 
 ## Whitelabeling Endpoints
 

^{How did I do? Any feedback?}