--- title: "Connect to a SQL Server node" description: "Connect to a self-managed SQL Server node over RDP, verify the database locally, then allow the SQL port from trusted sources." content_type: "how-to" product: "node" platform: "MyAccount" url: "/myaccount/node/how-to/connect-to-a-sql-node/" topic: ["create-and-connect"] --- # Connect to a SQL Server node A SQL Server node is a self-managed Windows node whose image or plan includes Microsoft SQL Server. You install, run, and manage the database yourself. That makes it different from a managed database service, where the provider runs the database for you. By the end you will be signed in over Remote Desktop and have confirmed SQL Server is running. You will also have chosen the network path your applications use to reach the database. You need the node's IP and the username and password from your creation email. ## Before you begin You need: - A SQL Server node. In **Compute > Nodes**, confirm you launched it from the **SQL Web** or **SQL Standard** image, or from a Windows plan that lists a SQL version. - A node in the **Running** state. - Remote Desktop access: TCP port **3389** reachable, and the username and password from your creation email. - A network path to the node: its public IP, or a private IP over the VPC, a VPN, or a bastion. A bastion is a jump server you connect through to reach a private network. - A SQL client, such as SQL Server Management Studio (SSMS) or `sqlcmd`. If you have not created the node yet, see [Create a node](/myaccount/node/how-to/create-a-node) and pick the **SQL Web** or **SQL Standard** image. The plan list shows the SQL version for these images. ## Find the node's IP Open the node's detail page in **Compute > Nodes** and copy its public IP. If your applications will reach the database over the VPC instead, use its private IP from the **Network** tab. ## Connect over Remote Desktop Open your RDP client and connect to the node's IP, then sign in with the username and password from your creation email. The flow is the same as for any Windows node; see [Connect to a Windows node](/myaccount/node/how-to/connect-to-a-windows-node). If RDP will not connect, fix Windows access before you troubleshoot SQL Server. Most first-time failures come from a blocked **3389**, an unreachable network path, or the wrong password. ## Check that SQL Server runs on the node Confirm SQL Server is running before you open any database port. Connect to it from inside the node first. 1. Open SQL Server Management Studio. 2. Connect to the local instance. Set server type to **Database Engine**, server name to `localhost`, and authentication to **Windows Authentication**. 3. In **New Query**, run a query that shows the installed edition. ```sql SELECT SERVERPROPERTY('Edition') AS Edition, SERVERPROPERTY('ServerName') AS ServerName; ``` The `Edition` value confirms what is actually installed, such as SQL Server Web Edition or SQL Server Standard Edition, rather than what the plan label says. If SSMS is not installed, use `sqlcmd` from a command prompt: ```powershell frame="none" sqlcmd -S localhost -E -Q "SELECT SERVERPROPERTY('Edition') AS Edition, @@VERSION AS VersionInfo;" ``` If `localhost` does not connect, the instance is probably a named one. Check the running services: ```powershell frame="none" Get-Service *SQL* ``` A default instance shows as `MSSQLSERVER`; a named instance shows as `MSSQL$` and connects with `localhost\`. ## Decide how applications will connect Choose the access model before you open the database port. - **Local only**: your application runs on the same node as SQL Server. Keep the database port closed and connect with `localhost`. - **Private network**: application nodes reach the database over the VPC. Allow SQL traffic only from private ranges or the application nodes' security groups. - **Restricted public access**: for temporary administration or a trusted external path. Allow the SQL port only from specific source IPs, never from `0.0.0.0/0`. For production, keep SQL Server private and put your application nodes on the same VPC. ## Allow the SQL port SQL Server's default instance listens on TCP **1433**. A named instance can use a different port, so confirm the listening port before you change any rule. A SQL Server node needs its **security group** as well as Windows Firewall to allow the SQL port from trusted sources. Both layers must agree: 1. In **Compute > Nodes**, open the node's **Security Group** tab. 2. Make sure a rule allows the SQL port, TCP **1433** by default, only from the source IPs or ranges your applications use. 3. On the node, allow the same port in Windows Firewall. For a named instance, use SQL Server Configuration Manager to confirm the port and that TCP/IP is enabled. Keep the rule as narrow as you can: allow only the clients that need the database. You can connect to a named instance directly by port with `node-ip,1433`, where `node-ip` is the node's IP and `1433` is the instance's port. That lets you skip opening UDP 1434, which keeps the firewall and security-group rules narrow. UDP 1434 is what the SQL Server Browser service uses to help clients discover a named instance's port. ## Common SQL Server connection problems | Problem | Likely cause | What to do | | ---------------------------------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | RDP will not connect | Port **3389** blocked, no reachable IP, or wrong password | Fix Windows access first; see the Windows node guide. | | SQL client cannot connect from another machine | SQL port blocked, TCP/IP disabled, or the security group does not allow the source | Confirm the listening port, then update Windows Firewall and the security group. | | SSMS cannot connect to `localhost` | Named instance, service stopped, or wrong authentication | Run `Get-Service *SQL*`, confirm the service, then try `localhost\`. | | `sqlcmd` is not recognized | SQL tools not installed or not in PATH | Use SSMS, or install the SQL Server command-line tools. | | Login fails | The SQL login, Windows login, authentication mode, or database permission is wrong | Connect locally as an administrator, verify the login type, then grant only the required permissions. | | Server was not found or was not accessible | Instance name, IP, port, route, service status, or SQL Server protocol is wrong | Verify the instance name, service status, TCP/IP, and port from inside the node. | | Port 1433 open but still no connection | Named instance on another port, or Windows Firewall blocks it | Confirm the actual listening port. | | Save Image is not offered | The node has an MS-SQL license | Back up the database itself; see [Enable backups on a node](/myaccount/node/how-to/enable-backups-on-a-node). | ## Security checklist Once the database is reachable, tighten it up: - Create application-specific SQL logins instead of sharing administrator credentials. - Use strong passwords and rotate temporary credentials. - Keep RDP restricted to trusted source IPs. - Keep Windows and SQL Server patched. - Monitor database growth alongside the node's other resources. - Back up the database before major changes, and test the restore steps before you rely on the backups for production recovery. ## Next steps with your SQL Server node Once SQL Server is reachable from the path your applications use, create the database and logins they need. Restrict access to only the clients that require it. Then take a database backup before you load production data, because **Save Image** is not offered on a node with an MS-SQL license. If a client still cannot reach the server, see [Troubleshooting node networking and connectivity](/myaccount/node/troubleshooting/networking-and-connectivity/#sql-server-connection-fails).