Application environment changes do not update existing Docker Swarm service environment

To Reproduce

1. Create an Application in Dokploy using Docker Swarm.
2. Set an environment variable, for example:
   DATABASE_URL=postgresql+psycopg://user:password@old-host:5432/database
3. Deploy the application.
4. Update the application environment in Dokploy to a new value:
   DATABASE_URL=postgresql+psycopg://user:password@new-host:5432/database
5. Save the environment.
6. Run Deploy, Redeploy, and/or Reload.
7. Inspect the environment of a newly created container/task.

Current vs. Expected behavior

Current behavior:

• Dokploy’s application configuration shows the updated environment value.
• The image is rebuilt successfully.
• New Docker Swarm tasks still receive the old environment variable value.
• Reload only restarts the existing service definition, retaining the stale environment.
• This makes it impossible to migrate an application from one database host to another through the Dokploy environment UI/API.
  Expected behavior:
• Saving environment variables followed by a deployment should update the Docker Swarm service specification.
• Newly created tasks should receive the saved/current environment variables.
• Reload should either apply the updated service environment or clearly state that a full service recreation is required.

Provide environment information

Self-hosted Dokploy
Application deployed on the same server where Dokploy is installed
Not using a remote server
Docker Swarm application
Python / FastAPI backend
PostgreSQL 18 service
Application was migrated from a Railway PostgreSQL URL to a Dokploy PostgreSQL URL

Which area(s) are affected? (Select all that apply)

Application, Docker Compose, Docker, Local Development

Are you deploying the applications where Dokploy is installed or on a remote server?

Same server where Dokploy is installed

Additional context

The saved application environment correctly contained the new database hostname, but inspecting the Docker configuration of every newly created Swarm task showed the previous Railway hostname. The rebuilt image did not contain the old value, confirming that the stale value was retained in the existing Swarm service specification.
Creating a new Dokploy application with the same source and current environment produced a container with the correct database hostname. This suggests the issue is specifically that Dokploy does not update an existing application’s Swarm service environment after an environment-variable change.

Will you send a PR to fix it?

Yes

Start by tracing the Docker Swarm application deployment path and how saved environment variables reach the existing service specification. Compare Deploy, Redeploy, and Reload behavior, then verify with a changed DATABASE_URL that newly created tasks receive the current value and no longer retain the previous hostname.