Add safe partial environment variable upsert API and MCP tool

What problem will this feature address?

Currently, application environment variables are updated through a full replacement operation such as:

application.saveEnvironment({
  applicationId,
  env,
  buildArgs,
  buildSecrets,
  createEnvFile
})

This is risky for API/MCP/agent usage when the current env is redacted. If an MCP client receives env: "[REDACTED]", it cannot safely add or update a single variable without knowing the full current env block.

Calling saveEnvironment with only the new variables may accidentally delete existing secrets such as database credentials, API keys, tokens, webhook secrets, and other production configuration.

This makes it unsafe to automate simple infrastructure tasks like: “create Redis and attach it to this application” without exposing all existing secrets to the MCP client or AI agent.

Describe the solution you'd like

Add a partial environment variable update endpoint for applications, and expose it through Dokploy MCP.

Example API:

application.env.upsert({
  applicationId,
  variables: {
    REDIS_HOST: "redis-dev",
    REDIS_PORT: "6379",
    REDIS_PASSWORD: "secret-value"
  },
  redeploy: true
})

Suggested input:

type UpsertApplicationEnvInput = {
  applicationId: string
  variables: Record<string, string>
  redeploy?: boolean
  dryRun?: boolean
  expectedRevision?: string
}

The server should read the current env internally, merge the submitted variables by key, save the resulting env, and optionally redeploy the application.

The response should not return raw values:

type UpsertApplicationEnvResult = {
  applicationId: string
  changed: boolean
  revision: string
  dryRun: boolean
  redeployed: boolean
  variables: Array<{
    name: string
    action: "created" | "updated" | "unchanged"
    secret: boolean
  }>
}

For MCP, expose a dedicated tool like:

application_env_upsert({
  applicationId: string,
  variables: Record<string, string>,
  redeploy?: boolean,
  dryRun?: boolean
})

This would let MCP clients add or update env variables without reading or exposing existing secrets.

Describe alternatives you've considered

1. Continue using `application.saveEnvironment`.

This works for UI full-block editing, but it is unsafe for MCP/automation when the current env is redacted. The client would need the complete env block, which either exposes secrets or risks deleting existing variables.

2. Manually update env variables in the Dokploy UI.

This is safe, but it prevents automation. For example, an MCP agent can create a Redis service, but cannot safely attach it to an application without asking the user to manually copy env variables.

3. Return the full env to trusted MCP clients.

This would solve the merge problem, but it exposes all secrets to the MCP client, chat logs, and automation context. A server-side partial update is safer.

Additional context

A useful verification model would be to return change metadata without returning secret values.

For example:

{
  "name": "REDIS_PASSWORD",
  "action": "updated",
  "secret": true
}

Dokploy could also expose:

• revision
• updatedAt
• updatedBy
• auditLogId
• dryRun result before applying changes

If secret change verification is needed, Dokploy could optionally return a server-side HMAC fingerprint change indicator, not the fingerprint itself by default:
fingerprint = HMAC_SHA256(serverSecret, value)

Plain hashes of secret values should be avoided because low-entropy secrets may be brute-forced. In most cases, returning created, updated, or unchanged plus an env revision and audit log is enough.

This feature would make Dokploy MCP much safer for AI agents and automation:

• no full env overwrite risk;
• no need to expose existing secrets;
• safer service-to-app wiring, such as Redis/Postgres/S3/ClickHouse;
• easier automated redeploy after env updates;
• better auditability without leaking secret values.

Implementation status

PR #4581 is open and ready for maintainer review: https://github.com/Dokploy/dokploy/pull/4581

The PR has been rebased on the latest canary, verified locally, and is currently waiting for maintainer review plus approval of the GitHub Actions workflow run for this fork PR. Current PR status: MERGEABLE, REVIEW_REQUIRED, Actions action_required.

Will you send a PR to implement it?

Yes - #4581 is ready for review

The issue points to PR #4581 as the implementation to review; begin there and compare it with the requested application partial-update API and MCP tool behavior. Done means the server merges variables without exposing existing values, reports the requested change metadata, and supports optional redeploy and dry-run behavior.