SQL Server 2025 Developer

Option A: Azure Portal

• Open the Ubuntu 24.04 VM with SQL Server 2025 Developer listing on the Azure Marketplace. Choose Get it now, then Create.
• Configure the basics:
• Subscription: select your Azure subscription.
• Resource Group: create a new group or select an existing one.
• Virtual Machine Name: enter a name for your VM.
• Region: select your preferred Azure region.
• Size: select a size for your workload.
• Under Administrator Account, select SSH public key and enter your key.
• Under Inbound Port Rules, allow SSH (port 22), ideally from your own network only. Do not open port 1433 to the internet.
• On the Networking tab, choose the virtual network your application servers use.
• Select Review + Create, then Create.

Option B: Azure CLI

The image carries a Marketplace purchase plan, so accept its terms once per subscription. Then create a network security group that allows SSH from your own network only, and create the virtual machine.

Replace <your-ip> with your workstation's public address and <your-vm-size> with the size you chose:

az vm image terms accept --urn sac1647283583153:mssql-2025-developer-ubuntu-24-04:default:latest
az network nsg create --resource-group myResourceGroup --name my-ssh-only-nsg
az network nsg rule create --resource-group myResourceGroup --nsg-name my-ssh-only-nsg \
  --name allow-ssh --priority 100 --protocol Tcp --destination-port-ranges 22 \
  --source-address-prefixes <your-ip>/32 --access Allow
az vm create \
  --resource-group myResourceGroup \
  --name my-mssql-vm \
  --image sac1647283583153:mssql-2025-developer-ubuntu-24-04:default:latest \
  --size <your-vm-size> \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --nsg my-ssh-only-nsg \
  --public-ip-sku Standard \
  --storage-sku StandardSSD_LRS \
  --query publicIpAddress -o tsv

The command prints the virtual machine's public IP address. To keep the database server off the internet entirely, add --public-ip-address "". Then reach the server through Azure Bastion, a VPN or a jump host on the same virtual network.

Step 9 shows how to let your application servers reach port 1433.

Run this command on your own workstation:

ssh azureuser@<vm-ip>

There is no password to enter. If SSH asks for one, your client is offering a different key from the one you supplied when you created the VM.

The first boot finishes within a minute or two of the virtual machine starting. Wait for it with:

sudo cloud-init status --wait

It prints status: done when the first boot has finished.

Confirm that both services are active once the first boot has finished:

systemctl is-active mssql-server mssql-firstboot

Expected output:

active active

Check for the marker file that the first-boot service leaves when it has run:

sudo test -f /var/opt/mssql/.firstboot-done && echo FIRSTBOOT_DONE

Confirm that SQL Server listens on port 1433 on all interfaces:

sudo ss -Htlnp '( sport = :1433 )' | awk '{print $4, $6}'

Expected output:

0.0.0.0:1433 users:(("sqlservr",pid=...,fd=...)) *:1433 users:(("sqlservr",pid=...,fd=...))

SQL Server also listens on the loopback address only, on ports 1431 and 1434, for its own local use. The network security group decides who can reach port 1433 from outside. The deployment above allows only SSH.

The first boot writes the logins to a root-only file. Check its permissions:

sudo stat -c '%a %U:%G %n' /stage/scripts/mssql-credentials.log

Expected output:

600 root:root /stage/scripts/mssql-credentials.log

To see the file, run sudo cat /stage/scripts/mssql-credentials.log. It holds SA_USER=sa, the SA password, SAC_USER=sac, the SecureAnyCloud password and SAC_DATABASE=sac.

The comment lines at the top of the file mention a Standard license key. They do not apply to this Developer Edition image (see Licensing above). Store the values in your secret store.

sqlcmd is already on your PATH. Load the SA password into the SQLCMDPASSWORD environment variable, which sqlcmd reads. The password then never appears on a command line or in the process list:

export SQLCMDPASSWORD="$(sudo awk -F= '$1=="SA_PASSWORD"{print $2}' /stage/scripts/mssql-credentials.log)" sqlcmd -S localhost -U sa -C -Q "SELECT @@VERSION;"

Expected output (first lines):

Microsoft SQL Server 2025 (RTM-CU4) (KB5081495) - 17.0.4035.5 (X64) Mar 29 2026 15:22:28 Copyright (C) 2025 Microsoft Corporation Enterprise Developer Edition (64-bit) on Linux (Ubuntu 24.04.4 LTS) <X64>

The -C flag tells sqlcmd to trust the server's self-generated certificate. sqlcmd 18 encrypts every connection by default. Without -C (or a certificate your clients trust), it stops with certificate verify failed:self-signed certificate.

Confirm the edition:

sqlcmd -S localhost -U sa -C -h -1 -W -Q "SELECT SERVERPROPERTY('Edition');"

Expected output:

Enterprise Developer Edition (64-bit)

Check that the connection is encrypted:

sqlcmd -S localhost -U sa -C -h -1 -W -Q "SELECT net_transport, encrypt_option, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID;"

Expected output:

TCP TRUE SQL

The first boot creates a SecureAnyCloud database (full recovery model, compatibility level 170) and a SecureAnyCloud login that is db_owner of it. Verify both:

sqlcmd -S localhost -U sa -C -h -1 -W -Q "SELECT name, recovery_model_desc, compatibility_level FROM sys.databases WHERE name = 'sac';" sqlcmd -S localhost -U sa -C -d sac -h -1 -W -Q "SELECT m.name, r.name FROM sys.database_role_members rm JOIN sys.database_principals r ON r.principal_id = rm.role_principal_id JOIN sys.database_principals m ON m.principal_id = rm.member_principal_id;"

Expected output:

sac FULL 170 dbo db_owner sac db_owner

Before you first use the SecureAnyCloud login, set its password to the per-VM value in the credentials file, signing in as SA. On the current image the login does not yet accept that value, so this step is required. The password is passed to sqlcmd on standard input, never on a command line:

CL_PASS="$(sudo awk -F= '$1=="SAC_PASSWORD"{print $2}' /stage/scripts/mssql-credentials.log)" printf "ALTER LOGIN [sac] WITH PASSWORD = N'%s';\nGO\n" "$CL_PASS" | sqlcmd -S localhost -U sa -C -b -i /dev/stdin unset CL_PASS

Then run a round trip as the SecureAnyCloud login:

SQLCMDPASSWORD="$(sudo awk -F= '$1=="SAC_PASSWORD"{print $2}' /stage/scripts/mssql-credentials.log)" \
  sqlcmd -S localhost -U sac -C -d sac -h -1 -W \
  -Q "CREATE TABLE ##probe (id INT, val NVARCHAR(64)); INSERT INTO ##probe VALUES (1, N'sac-ok'); SELECT val FROM ##probe WHERE id = 1; DROP TABLE IF EXISTS ##probe;"

The output includes sac-ok.

SQL Server 2025 adds a native VECTOR type with VECTOR_DISTANCE, regular expression functions such as REGEXP_LIKE, and JSON constructors such as JSON_OBJECT. Try them with a quick test in the SecureAnyCloud database:

sqlcmd -S localhost -U sa -C -d sac -h -1 -W -Q " CREATE TABLE dbo.docs (id INT PRIMARY KEY, title NVARCHAR(100), embedding VECTOR(3)); INSERT INTO dbo.docs VALUES (1, N'Azure VM guide', '[0.1,0.9,0.2]'), (2, N'SQL Server notes', '[0.8,0.1,0.3]'), (3, N'Ubuntu tips', '[0.2,0.8,0.1]'); SELECT TOP 2 id, title, CAST(VECTOR_DISTANCE('cosine', embedding, CAST('[0.1,0.9,0.1]' AS VECTOR(3))) AS DECIMAL(6,4)) AS dist FROM dbo.docs ORDER BY dist; SELECT id, title FROM dbo.docs WHERE REGEXP_LIKE(title, '^(Azure|Ubuntu)'); SELECT JSON_OBJECT('id': id, 'title': title) FROM dbo.docs WHERE id = 2; DROP TABLE dbo.docs;"

Expected output:

1 Azure VM guide .0058 3 Ubuntu tips .0089 1 Azure VM guide 3 Ubuntu tips {"id":2,"title":"SQL Server notes"}

SQL Server writes backups as the mssql user, so back up to a directory that user owns, such as the default data directory:

sqlcmd -S localhost -U sa -C -Q "BACKUP DATABASE sac TO DISK = N'/var/opt/mssql/data/sac.bak' WITH INIT, COMPRESSION; RESTORE VERIFYONLY FROM DISK = N'/var/opt/mssql/data/sac.bak';"

Expected output (last lines):

BACKUP DATABASE successfully processed ... pages in ... seconds (...). The backup set on file 1 is valid.

Copy backups off the virtual machine, for example to Azure Blob Storage, so they survive the loss of the disk.

SQL Server listens on port 1433 on every interface, but the network security group from Step 1 allows only SSH. To let your application servers connect, add a rule that allows port 1433 from their subnet only:

az network nsg rule create --resource-group myResourceGroup --nsg-name my-ssh-only-nsg \
  --name allow-sql-from-apps --priority 110 --protocol Tcp --destination-port-ranges 1433 \
  --source-address-prefixes <app-subnet-cidr> --access Allow

Applications then connect to the virtual machine's private IP address on port 1433 with a SQL login, for example sqlcmd -S <private-ip>,1433 -U SecureAnyCloud -C -d SecureAnyCloud (with the password in SQLCMDPASSWORD).

SQL Server Management Studio and other TDS clients connect the same way. They must trust the server certificate, as -C does. Alternatively, install a certificate of your own with mssql-conf set network.tlscert.

To work from your own workstation without opening port 1433, open an SSH tunnel and point your client at localhost,14330:

ssh -N -L 14330:localhost:1433 azureuser@<vm-ip>

Do not open port 1433 to the internet.

Key components and their paths:

• SQL Server engine: /opt/mssql/bin/sqlservr
• Configuration tool: /opt/mssql/bin/mssql-conf
• Configuration file: /var/opt/mssql/mssql.conf
• sqlcmd and bcp: /opt/mssql-tools18/bin/
• Data directory: /var/opt/mssql/data/
• Error log: /var/opt/mssql/log/errorlog
• Service unit: /usr/lib/systemd/system/mssql-server.service
• First-boot unit: /etc/systemd/system/mssql-firstboot.service
• First-boot script: /usr/local/sbin/mssql-firstboot.sh
• First-boot marker: /var/opt/mssql/.firstboot-done
• Credentials file: /stage/scripts/mssql-credentials.log

The data and log files live on the OS disk. For larger databases, attach a data disk and mount it. Then move the default data and log directories to it with mssql-conf set filelocation.defaultdatadir and filelocation.defaultlogdir.

SQL Server Agent is not enabled on this image. Turn it on with sudo /opt/mssql/bin/mssql-conf set sqlagent.enabled true, then run sudo systemctl restart mssql-server.

Check the installed package versions:

dpkg -l mssql-server mssql-tools18 | awk '/^ii/{print $2, $3}'

sudo systemctl status mssql-server --no-pager sudo systemctl restart mssql-server
sudo tail -n 50 /var/opt/mssql/log/errorlog

Ubuntu's unattended upgrades install Ubuntu security updates automatically. SQL Server comes from Microsoft's own repository, so update it yourself when a new cumulative update is available:

sudo apt-get update apt-cache policy mssql-server
sudo apt-get install --only-upgrade mssql-server

The upgrade restarts SQL Server. Take a backup first and run the upgrade during a quiet period.

sqlcmd says certificate verify failed:self-signed certificate

• Add -C to trust the server's certificate, or install a certificate your clients trust (Step 9).

Login failed for user 'SecureAnyCloud'

• Set the SecureAnyCloud password from the credentials file as SA (Step 6), then try again.
• Find the reason in the error log: sudo grep "Login failed" /var/opt/mssql/log/errorlog | tail -5

Cannot connect on port 1433 from another host

• Check the service and listener (Step 3).
• Check that the network security group allows 1433 from your client's subnet (Step 9).

The first boot did not finish

Check the first-boot service and its journal:

• sudo systemctl status mssql-firstboot --no-pager
• sudo journalctl -u mssql-firstboot --no-pager -n 50

The server name looks wrong

• SELECT @@SERVERNAME reports the name of the machine the image was built on, while SERVERPROPERTY('MachineName') reports your virtual machine's name.
• Features that depend on the server name, such as replication, need the server renamed first. Follow Microsoft's procedure for renaming a SQL Server host.

• Keep port 1433 private. Keep it closed to the internet and allow it only from your application subnets.
• Set the SecureAnyCloud password early. Set the login's password (Step 6) before port 1433 is reachable from any other host.
• Use one login per application. Grant only the permissions each application needs, and do not connect applications as SA.
• Rotate the SA password. Change it on a schedule with ALTER LOGIN [sa] WITH PASSWORD = ..., or disable SA once named administrator logins exist.
• Keep passwords off the command line. Use SQLCMDPASSWORD or a secret store rather than -P.
• Back up regularly. Take regular backups and copy them off the virtual machine.
• Remove the credentials file when you no longer need it. Once the passwords are in your secret store, delete the file with sudo shred -u /stage/scripts/mssql-credentials.log.

Sign in to the AWS Management Console, open the EC2 service and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for SQL Server 2025.

Select the SecureAnyCloud listing and choose Select. On the subscription summary, pick the SQL Server 2025 Developer on Ubuntu 24.04 delivery option and choose Continue.

Pick an instance type that suits your workload (see Prerequisites). Choose your EC2 key pair under Key pair (login).

Under Network settings, select your VPC and subnet. Create or select a security group that allows inbound port 22 from your management network. Add port 1433 to the security group if you want external clients to connect to SQL Server directly. Leave the root volume at the default size or larger.

Select Launch instance. First-boot initialization generates the SA password and starts SQL Server. It takes a minute or two after the instance state becomes Running and the status checks pass.

The following command launches an instance from the SecureAnyCloud SQL Server 2025 Developer Marketplace AMI into an existing subnet and security group. Replace the values as follows:

• <ami-id>: the AMI ID shown on the Marketplace listing for the Developer delivery option
• <key-name>: your EC2 key pair name
• <subnet-id>: your subnet ID
• <security-group-id>: a security group that opens inbound port 22 (and optionally 1433 for external SQL connections)

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.xlarge \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --metadata-options HttpTokens=required \
  --block-device-mappings '[{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":40,"VolumeType":"gp3"}}]' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=mssql-01}]'

On success, the command prints a JSON document. Note the instance ID, then retrieve the instance's public address once it is running:

aws ec2 describe-instances \
  --instance-ids <instance-id> \
  --query "Reservations[].Instances[].PublicIpAddress" \
  --output text

Connect over SSH with the key pair you selected and the public IP address from Step 2. This delivery option is built on Ubuntu 24.04, so the SSH login user is ubuntu:

ssh ubuntu@<your-instance-ip>

Wait until the instance has passed both EC2 status checks before you connect. The first-boot service runs before the SSH daemon is ready, so SQL Server is initialized by the time you can log in.

The first-boot service generates a fresh SA password for this instance and writes it, with the connection details, to /root/mssql-credentials.txt. Only the root user can read the file. Display it from your SSH session:

sudo cat /root/mssql-credentials.txt

The file looks like this, with unique passwords on your instance:

# SQL Server 2025 Developer Edition -- Per-Instance Credentials
# Generated: Wed Jun 04 09:00:00 UTC 2026
# Instance IP: 3.86.159.217
# SA_USER=SA SA_PASSWORD=<set-at-first-boot> SAC_USER=sac SAC_PASSWORD=<set-at-first-boot> SAC_DATABASE=sac
#
# Connect: sqlcmd -S 3.86.159.217 -U SA -P 'Az6b3036366161212d18!fec2e071' -C

Keep this file secure, because it contains the SA password for the SQL Server instance. The SecureAnyCloud login is a member of db_owner on the SecureAnyCloud database and is suitable for application connections.

The sqlcmd command-line utility is preinstalled at /opt/mssql-tools18/bin/sqlcmd. Connect to the local SQL Server instance using the SA password from the credentials file:

SA_PASS=$(sudo grep '^SA_PASSWORD=' /root/mssql-credentials.txt | cut -d= -f2-) /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U SA -P "${SA_PASS}" -C

The -C flag trusts the server certificate, because the image uses a self-signed certificate. At the 1> prompt, run T-SQL statements. Type GO to execute a batch and exit to quit.

Verify the SQL Server version and confirm the Developer edition:

SA_PASS=$(sudo grep '^SA_PASSWORD=' /root/mssql-credentials.txt | cut -d= -f2-) /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U SA -P "${SA_PASS}" -C -Q "SELECT @@VERSION"

Output from this instance:

Microsoft SQL Server 2025 (RTM-CU5-GDR) (KB5095565) - 17.0.4050.1 (X64) May 15 2026 12:06:45 Copyright (C) 2025 Microsoft Corporation Developer Edition (64-bit) on Linux (Ubuntu 24.04.4 LTS) <X64>

SQL Server runs as a systemd service. Check its status:

sudo systemctl status mssql-server --no-pager

Expected output:

mssql-server.service - Microsoft SQL Server Database Engine Loaded: loaded (/usr/lib/systemd/system/mssql-server.service; enabled; preset: enabled) Active: active (running) since Wed 2026-06-04 09:00:35 UTC; 16s ago Docs: https://docs.microsoft.com/en-us/sql/linux Main PID: 6640 (sqlservr) Tasks: 87 Memory: 503.9M (peak: 503.9M) CPU: 8.057s

Manage the service with standard systemctl commands:

sudo systemctl stop mssql-server
sudo systemctl start mssql-server
sudo systemctl restart mssql-server

Connect to SQL Server and create a database with the following commands:

SA_PASS=$(sudo grep '^SA_PASSWORD=' /root/mssql-credentials.txt | cut -d= -f2-) /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U SA -P "${SA_PASS}" -C -Q "IF DB_ID('myapp') IS NULL CREATE DATABASE [myapp];" /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U SA -P "${SA_PASS}" -C -d myapp -Q "IF OBJECT_ID('customers') IS NULL CREATE TABLE customers (id INT IDENTITY PRIMARY KEY, name NVARCHAR(100), email NVARCHAR(200), created_at DATETIME2 DEFAULT GETDATE()); INSERT INTO customers (name, email) VALUES ('Alice Smith', 'alice@example.com'); INSERT INTO customers (name, email) VALUES ('Bob Jones', 'bob@example.com'); SELECT id, name, email, created_at FROM customers;"

Sample output:

id name email created_at -- ----------- ------------------ -------------------------- 1 Alice Smith alice@example.com 2026-06-04 09:05:00.0000000 2 Bob Jones bob@example.com 2026-06-04 09:05:00.1000000 (2 rows affected)

SQL Server listens on port 1433. To connect from a remote machine, add port 1433 to the inbound rules of the instance's security group. Then connect with any SQL Server-compatible client, such as SQL Server Management Studio, Azure Data Studio, DBeaver, or sqlcmd on another machine:

/opt/mssql-tools18/bin/sqlcmd -S <your-instance-ip>,1433 -U SA -P "<SA_PASSWORD>" -C

For production deployments, enable SSL/TLS with a trusted certificate. See the Microsoft documentation on SQL Server on Linux encryption.

The mssql-conf utility manages SQL Server configuration. List the current settings:

sudo /opt/mssql/bin/mssql-conf list

Set the maximum server memory. Replace 8192 with your limit in MB:

sudo /opt/mssql/bin/mssql-conf set memory.memorylimitmb 8192
sudo systemctl restart mssql-server

The first-boot service removes the build-time memory cap automatically. SQL Server therefore starts with no explicit memory limit on your instance, within the edition's own buffer-pool ceiling. Set an explicit limit only if you need to share the host with other workloads.

Create the backup directory, then back up the SecureAnyCloud database to a local file:

sudo mkdir -p /var/opt/mssql/backup
sudo chown mssql:mssql /var/opt/mssql/backup
SA_PASS=$(sudo grep '^SA_PASSWORD=' /root/mssql-credentials.txt | cut -d= -f2-) /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U SA -P "${SA_PASS}" -C -Q \
  "BACKUP DATABASE [sac] TO DISK = N'/var/opt/mssql/backup/sac.bak' WITH INIT, COMPRESSION;"

Restore from a backup file:

SA_PASS=$(sudo grep '^SA_PASSWORD=' /root/mssql-credentials.txt | cut -d= -f2-) /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U SA -P "${SA_PASS}" -C -Q \
  "RESTORE DATABASE [sac] FROM DISK = N'/var/opt/mssql/backup/sac.bak' WITH REPLACE;"