feat(compose): add configurable MTU for isolated networks

[Hobby-Student]

What is this PR about?

It's about setting MTU on docker compose (not swarm).

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)

#3446

Screenshots (if applicable)

Greptile Summary

This PR adds a configurable MTU option for isolated Docker Compose networks, allowing users to set a custom MTU (e.g., 1350 for VPN/overlay environments) when isolated deployment is enabled. The database migration, schema, UI field, and shell command generation all follow established patterns in the codebase.

Key findings:

• Accidental .env.production file — an empty file was committed that is unrelated to this feature and should be removed before merge.
• Missing <FormMessage /> in the MTU input field — Zod validation errors (out-of-range values) will be silently swallowed and the form will appear to do nothing, with no feedback to the user.
• Zod schema should use .int() — MTU values are always whole numbers; accepting floats allows values like 1499.5 that PostgreSQL silently truncates to an integer.
• The MTU flag is correctly gated behind composeType !== "stack", since Docker overlay/swarm networks do not support the --opt com.docker.network.driver.mtu flag.
• The integer DB column means the shell-interpolated value is safe from injection.

Confidence Score: 3/5

• Not ready to merge — the accidental .env.production commit and missing form validation feedback need to be addressed first.
• The core feature logic is sound (correct shell command, correct DB migration, correct overlay guard), but the accidentally committed .env.production file is a clear mistake that must be reverted, and the missing FormMessage means users get no feedback when they enter an invalid MTU value, which is a noticeable UX regression on a newly added form field.
• .env.production (should not be committed) and apps/dokploy/components/dashboard/compose/advanced/add-isolation.tsx (missing FormMessage, missing .int() validation).

Comments Outside Diff (1)

1. .env.production, line 1 (link)

   Accidental empty file committed

   An empty .env.production file has been added to the repository. This file appears to be accidentally included in this PR — it has no relation to the MTU feature and should not be committed.

   Production environment files typically contain sensitive credentials and are expected to be in .gitignore. Committing an empty one can mislead maintainers or cause issues if the real populated file is later committed on top of it.

_{Reviews (1): Last reviewed commit: "feat(compose): add configurable MTU for ..." | Re-trigger Greptile}

Greptile also left 2 inline comments on this PR.

_{(2/5) Greptile learns from your feedback when you react with thumbs up/down!}

[dosubot]

Related Documentation

2 document(s) may need updating based on files changed in this PR:

Dokploy's Space

AGENTS /templates/blob/canary/AGENTS.md

View Suggested Changes

@@ -147,7 +147,7 @@
 - **Docker Compose Conventions (CRITICAL):**
 
   - **Version:** MUST be `3.8`
-  - **NEVER include:** `ports` (use `expose` only), `container_name`, `networks` (Dokploy handles isolation)
+  - **NEVER include:** `ports` (use `expose` only), `container_name`, `networks` (Dokploy handles isolation). **Note:** While templates should not include network configuration, Dokploy supports configurable MTU (Maximum Transmission Unit) for isolated networks through the UI (range: 68-9000, default: 1500, recommended for VPN/overlay: 1350). This is a user-facing feature for advanced network configuration without requiring template modifications.
   - **ALWAYS include:** `restart: unless-stopped` or `restart: always`, persistent volumes
   - **Service naming:** MUST match blueprint folder name exactly
   - **Example:**

[Accept] [Decline]

copilot-instructions /templates/blob/canary/.github/copilot-instructions.md

View Suggested Changes

@@ -61,7 +61,7 @@
   - Mounts: `[[config.mounts]] filePath = "/etc/config" content = """multi-line\ncontent"""`.
   - JWT helper: `${jwt:secret_var:payload_var}` for auth tokens; payload as JSON string with `exp: ${timestamps:YYYY-MM-DDTHH:mm:ssZ}`.
 - **Meta.json**: Entries as JSON objects; tags array of lowercase strings (e.g., ["monitoring", "database"]); links object with `github`, `website`, `docs`.
-- **No Networks**: Rely on Dokploy's isolated deployments—avoid explicit `networks:`.
+- **No Networks**: Templates should avoid explicit `networks:` configuration and rely on Dokploy's isolated deployments. Dokploy automatically creates isolated networks for each deployment and handles service connectivity. For advanced users, Dokploy supports configuring the MTU (Maximum Transmission Unit) for these isolated networks through the UI (typically 1350 for VPN/overlay environments, default 1500). This is a deployment-time configuration—template authors should not include MTU settings in their templates.
 - **Versions**: Pin images to specific versions in `docker-compose.yml` (e.g., `ghost:5.82.0-alpine`); match in `meta.json.version`. **NEVER use `latest` tag**—it can break templates when upstream images change unexpectedly. **Always verify image exists** using `docker manifest inspect <image:tag>` before committing.
 - **Logos**: SVG preferred; size ~128x128; file name in `meta.json.logo` (e.g., "ghost.svg").
 

[Accept] [Decline]

Note: You must be authenticated to accept/decline updates.

^{How did I do? Any feedback?}  

[Hobby-Student]

I updated the PR accordingly to the suggestions.

[mahdirajaee]

Good feature addition — configurable MTU is a real need for users running behind VPN or overlay networks. The Zod validation with z.number().int().min(68).max(9000) is solid and covers the practical MTU range correctly, and I appreciate that .int() is included to reject fractional values. The guard for composeType !== "stack" in the shell command is correct since overlay/swarm networks don't support the --opt com.docker.network.driver.mtu flag.

One concern with the network creation command: the docker network inspect ... || docker network create ... pattern means if a network already exists with a different MTU, the new MTU value will be silently ignored. It might be worth documenting this behavior or, alternatively, checking the current MTU and warning/recreating if it differs — otherwise users will change the MTU in the UI and see no effect until they manually remove the old network.

The DB migration is clean and the nullable integer column is the right choice. Minor nit: the migration SQL file is missing a trailing newline (\ No newline at end of file), which some linting tools will flag.

[Hobby-Student]

One concern with the network creation command: the docker network inspect ... || docker network create ... pattern means if a network already exists with a different MTU, the new MTU value will be silently ignored. It might be worth documenting this behavior or, alternatively, checking the current MTU and warning/recreating if it differs — otherwise users will change the MTU in the UI and see no effect until they manually remove the old network.

I think recreating is difficult, because the network could be used by other compose files. this could break working connections and trigger unwanted side effects. perhaps documenting and log an info in deployment is the right way? What do you think?

The DB migration is clean and the nullable integer column is the right choice. Minor nit: the migration SQL file is missing a trailing newline (\ No newline at end of file), which some linting tools will flag.

will fix this, too.