feat!: Network Management System v1

[chichi13]

What is this PR about?

Breaking Change

This PR introduces a complete redesign of network management in Dokploy, replacing the legacy isolatedDeployment feature with a flexible custom network system.

---

Overview

This PR implements comprehensive Docker network management as a core feature of Dokploy. Users can now create, manage, and assign custom Docker networks to any resource type (applications, compose services, databases) with full control over network configuration, IPAM settings, and driver selection.

---

Major Changes

Network Management System

• Global Network Management UI: New /dashboard/networks page for organization-wide network administration
• Resource-Level Network Assignment: Integrated network management into all resource types (applications, compose, databases)
• Project Organization: Added dedicated networks tab to project views for better organization

Database Schema

New network Table

• Multiple network drivers: bridge and overlay
• Advanced IPAM configuration: subnet, gateway, IP range
• Network encryption support for overlay networks
• Organization scope
• Docker network ID tracking for synchronization

Resource Schema Updates

• Added customNetworkIds field to all resource types:
  • application
  • compose
  • postgres, mysql, mariadb, mongo, redis
• Supports multiple network assignments per resource

Network Features

Automatic Traefik Integration

• Traefik automatically connects to custom networks when domains are added to resources
• Automatic disconnection when networks are no longer in use by resources with domains
• Ensures proper routing without manual network configuration

Driver Validation

• Enforces overlay networks for Docker Swarm services
• Enforces overlay networks for compose stacks
• Bridge networks allowed for standard docker-compose mode

Network Synchronization (based on labels)

• Sync functionality to detect discrepancies between Docker and database state
• Identifies missing networks (in DB but not in Docker)
• Identifies orphaned networks (in Docker but not in DB)
• Import orphaned networks with proper label validation

Migration and Backward Compatibility

Migration 0117: Add Network table and add customNetworkIds field

Migration 0118: Convert isolatedDeployment to customNetworkIds

This migration automatically converts all existing compose services using isolatedDeployment=true to the new network system:

1. Scans all compose services with isolatedDeployment=true
2. Creates network records using the compose appName as the network name
3. Assigns appropriate driver (overlay for remote servers, bridge for local)
4. Links networks to compose services via customNetworkIds
5. Sets isolatedDeployment=false on migrated services

Context: Compose services with isolated deployment already have Docker networks created with name = compose.appName. The migration imports these existing networks into the database and establishes proper tracking.

Migration 0119: Remove isolatedDeployment Field

Removes the obsolete isolatedDeployment boolean field from the database schema after successful migration.

---

Testing

New Test Coverage

• Network Service Tests (network-service.test.ts):

  • CRUD operations
  • Resource assignment/removal
  • Traefik integration
  • Sync and import functionality

• Compose Network Integration (compose-networks.test.ts):

  • Compose-specific network behavior
  • Stack vs docker-compose mode validation

• Schema Validation (schema.test.ts):

  • Network configuration validation
  • IPAM parameter validation
  • Driver validation

---

Breaking Changes

Removed: isolatedDeployment Field

The isolatedDeployment boolean field has been removed from the compose table schema.

Migration: All existing data is automatically migrated via migration 0118. No manual intervention required for Dokploy users.

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.

Issues related

closes #2798
closes #1495

Screenshots

[chichi13]

@Elvinra Okay so I've resolved the conflicts.

I cannot select dokploy-network in the domain modal, if i have any non public network attached to the application, pretty sure the problem exists on preview deployments.

I didn't quite understand when I replied the other day, but that's the expected behavior. The domain cannot be on dokploy-network since the application itself is only on the custom network (Production for example in my screen).

You can only choose the networks (except internal networks) on which your app is located.

---

Image updated

[Edgar-Alarcon]

Hi @Elvinra and @chichi13,

I'm following the progress of the Network Management PR, and since it introduces important improvements, I wanted to ask if there’s any update on its review or its chances of being approved.

Thanks for your time and for all the work on the project!

[chichi13]

Hi @Edgar-Alarcon

I talked to @Siumauricio 2 days ago on discord, he has already looked at the PR but needs more time to do a full review and suggest improvements. He will try to work on it in the next few days.

[Edgar-Alarcon]

Great, thank you @chichi13

[chichi13]

Unfortunately, no news for this PR...

[hijak]

Let's go with this feature!

[Hraph]

@Siumauricio do something, delegate if you don't have time, too many PRs have been waiting for months. Wanting to control everything yourself goes against the spirit of the open source community...

[david-breidert]

@Siumauricio when can we expect to have this feature merged? It is a priority for lots of people.

[javierwo]

Just faced this problem today while trying to connect PgBouncer with Postgres (from UI). This feature will be very useful as dokploy-network seems to be accessible across all projects.

[Siumauricio]

Can you resolve conflicts? @chichi13

[chichi13]

Can you resolve conflicts? @chichi13

I will check that today/tomorrow!

[chichi13]

@Siumauricio merge done

I struggled a bit, but everything should be fine. However, I get errors from the "canary" branch when I go to the project list:

❌ tRPC failed on project.all: cannot pass more than 100 arguments to a function
 GET /api/trpc/project.all?batch=1&input=%7B%220%22%3A%7B%22json%22%3Anull%2C%22meta%22%3A%7B%22values%22%3A%5B%22undefined%22%5D%2C%22v%22%3A1%7D%7D%7D 500 in 116ms (compile: 2ms, render: 114ms)

[chichi13]

Okay, I understand.

With the new migrations since the PR opened in October, some queries return more than 100 columns. Drizzle ORM limits to 100 columns, and we were at... 101.

So I fixed the problem by specifying the columns. We've gone from 101 columns returned to ~7.

[peteragurto]

Okay, I understand.

With the new migrations since the PR opened in October, some queries return more than 100 columns. Drizzle ORM limits to 100 columns, and we were at... 101.

So I fixed the problem by specifying the columns. We've gone from 101 columns returned to ~7.

@Siumauricio I think it's time

[Siumauricio]

@Siumauricio do something, delegate if you don't have time, too many PRs have been waiting for months. Wanting to control everything yourself goes against the spirit of the open source community...

I think we need to be more considerate of the time required for each feature. If a PR is not merged or reviewed, it is simply because it does not meet coding standards, especially for such a large feature. I am not going to merge a PR that does not meet the expectations of people who use dokploy.

Unfortunately, AI moves so fast and sometimes we have too many PRs with AI. I'm not saying that's bad, it's just that the standard isn't being followed and this makes review very, very difficult.

I have reviewed this PR and it definitely needs a lot of changes in terms of improving code quality (making it simpler, for example, or following the same structure that we follow throughout the project). That is why, if you see a PR that is not merged, it is simply because it does not follow our standards, and the best and easiest thing to do is to simply close the PR and create the functionality from scratch unfortunately. It saves time.

[chichi13]

I have reviewed this PR and it definitely needs a lot of changes in terms of improving code quality (making it simpler, for example, or following the same structure that we follow throughout the project). That is why, if you see a PR that is not merged, it is simply because it does not follow our standards, and the best and easiest thing to do is to simply close the PR and create the functionality from scratch unfortunately. It saves time.

I was expecting another separate message about the PR itself (I still spent more than 7 human days on the feature). Rereading the code, I'm not sure I understand what you mean by "needs a lot of changes in terms of improving code quality (making it simpler, for example, or following the same structure that we follow throughout the project)."

Can you elaborate a little more?

For me, this PR is not just a network feature, but a security flaw fix. Currently, a hacker who performs privilege escalation in a container could access all containers deployed on our dokploy, since there is no network isolation for most applications.

[ishvedov]

@chichi13 #3774

[chichi13]

Thanks @ishvedov

It's a shame there wasn't clear communication (the only comment being to highlight a negative comment rather than my work), but if the feature is implemented as he wants, everyone will be happy.

[peteragurto]

Thanks @ishvedov

It's a shame there wasn't clear communication (the only comment being to highlight a negative comment rather than my work), but if the feature is implemented as he wants, everyone will be happy.

I think he needs more "core" collaborators for this project, its getting bigger