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 Thanks for these tests!

I did more extensive testing, but I forgot some basic tests.

4. Add a domain with the default network KO

This was “normal,” but it could be confusing, so I changed how it works so that the backend sends the available network data.

6. Delete the domain KO

I was using the wrong networkId, but this has now been corrected. When deleting/editing/adding, the domain should detach from the network UNLESS it is used for another domain in an app.

Image updated docker pull achichi13/dokploy:network-pr

[Elvinra]

Hello,

You have a migration conflict between the main repository and yours.
The migration 116, 117 exists in both repository.

I run the migration manually for testing, and i saw only one regression.

• 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.

[chichi13]

Hello @Elvinra

New migrations have been added to canary branch. So I'll need to merge canary to this branch and resolve conflict.

Thanks for testing and pointing out the regression. I'll try to resolve the problem this week.

A comment from @Siumauricio to get hist opinion for the PR would be great tbh

[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