Custom Port Support in Azure Database for MySQL – Flexible Server is Now Generally Available
We are excited to announce that custom port support for Azure Database for MySQL – Flexible Server is now generally available (GA). This long-requested feature gives you greater flexibility to align MySQL server deployments with your network and security requirements. By default, MySQL uses TCP port 3306; with this GA release, you can configure a custom port (between 25001 and 26000) when creating a new Azure Database for MySQL flexible server. This enables easier integration with legacy applications, helps comply with strict network security policies, and avoids port conflicts in complex environments. What’s new in GA (vs. Public Preview): In the Public Preview (July 2025), custom ports were only supported for VNet-injected (private access) servers, with no support for public access or Private Link connectivity. Now, with GA, you can create custom-port servers in any network configuration – including both publicly accessible servers and those using Private Link (private endpoint) connectivity. In short, all new MySQL flexible servers can be created with a custom port, whether they are configured for public network access or deployed into a private virtual network. Feature Highlights Custom Port Range: Choose a port between 25001 and 26000 during server provisioning. (Only one custom port is supported per server.) This is in addition to the default MySQL port 3306, which remains available for use if needed. Supported Scenarios: Custom ports are fully supported for new server creation, point-in-time restore (including cross-port restores), read replica setup, and High Availability (HA) deployments. You can perform a restore or set up a replica even if the source and target servers use different ports, and you can enable HA on a server configured with a non-default port. Networking Flexibility: Supported on both public access and private access configurations. You can create servers with a custom port in public access mode (accessible via the internet with firewall rules) or in private access mode (injected into a VNet). Azure Private Link is also supported – meaning you can connect via a private endpoint to a MySQL server running on a custom port. This enhancement broadens the feature’s applicability beyond the preview’s limited scope, allowing usage in all network scenarios. Managed Experience: The custom port feature is built into the managed service experience. Aside from specifying a different port number for client connections, there is no change in how you manage or operate the MySQL flexible server – all administrative capabilities and integrations (backup, monitoring, etc.) work as they do with the default port. Current Limitations Be aware of a couple of limitations at GA: Port Immutable After Creation: You cannot change the server’s port after the server is created. If you need to use a different port, you will have to create a new server with that port. As a workaround, you can use Point-in-Time Restore (PITR) to quickly clone your database into a new server with the desired port (since cross-port restores are supported), rather than performing a full manual migration. Geo-Replication/Geo-Restore: Cross-region operations like geo-restore and geo-replication are not yet supported for servers using a custom port. In other words, you cannot perform a geo-restore of a backup from a custom-port server, and you cannot create cross-region read replicas on custom port servers at this time. These capabilities are on the roadmap but remain unsupported in the current release. Why Custom Ports? Many enterprise developers and DBAs have asked for custom port support to accommodate specialized network scenarios. For example, some organizations enforce strict firewall rules or use non-standard ports for databases to meet internal security compliance requirements. Others may have legacy applications or multi-database setups that require MySQL to run on a port other than 3306 to avoid conflicts. The custom port feature addresses these needs by allowing you to select a non-default port during server creation, while Azure continues to handle all the usual PaaS management tasks. In short, you get the flexibility of a custom network configuration without losing the benefits of a fully managed database service. Getting Started Using a custom port is straightforward. At GA, the Azure portal’s create experience is the way to set a custom port (support in CLI/PowerShell/ARM will come later). In the portal, when you create a new Azure Database for MySQL – Flexible Server, you’ll find an option to specify the “Database port.” Provide any value between 25001 and 26000 as the port number for your server. Once the server is deployed, client applications should connect using the <servername>.mysql.database.azure.com hostname and the port you chose, instead of the default 3306. All other connection settings (such as SSL enforcement and credentials) remain the same. Make sure to configure network access rules to allow traffic on your chosen port. For public access servers, this means updating the firewall rules or network security groups to permit the custom port. For private access or Private Link setups, ensure that your networking (NSGs, on-premises firewall rules, etc.) permits traffic on the custom port to reach the database. Learn More Custom port support is now GA and ready for production use, so we encourage you to try it out if your environment can benefit from it. For more details on Azure Database for MySQL – Flexible Server connectivity and custom ports, refer to the official documentation: Networking Overview - Azure Database for MySQL | Microsoft Learn We look forward to seeing how you use this new capability to tailor your MySQL deployments. With custom port support now generally available, Azure Database for MySQL – Flexible Server offers even more flexibility to meet your organizational policies and integration needs, all while delivering a fully managed experience. Happy deploying!Transition from VNET integration to public access or Private Link using the Azure CLI
This post provides two bash scripts that use the Azure CLI to transition an Azure Database for MySQL flexible server from VNET Integrated to Public Access or a Private Link. You can run these bash scripts either locally or by using the Azure Cloud Shell.
