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.
Will you send a PR to implement it?
No
What problem will this feature address?
Currently, application environment variables are updated through a full replacement operation such as:
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:
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:
For MCP, expose a dedicated tool like:
This would let MCP clients add or update env variables without reading or exposing existing secrets.
Describe alternatives you've considered
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:
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:
Will you send a PR to implement it?
No