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

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.

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:

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:

Get-Service *SQL*

A default instance shows as MSSQLSERVER; a named instance shows as MSSQL$<instance-name> and connects with localhost\<instance-name>.

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\<instance-name>.
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.

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.