Deploy SQL Server

Deploy and Host SQL Server on Railway

SQL Server is Microsoft's enterprise-grade relational database platform for transactional applications, APIs, business systems, analytics workloads, and data-driven services. It provides SQL, ACID transactions, indexing, stored procedures, security controls, JSON support, and broad compatibility with Microsoft, Java, Python, Node.js, and other application ecosystems.

About Hosting SQL Server

Hosting SQL Server on Railway gives you a persistent relational database without manually managing a virtual machine, operating system, database installation, or server lifecycle.

This template runs the official Microsoft SQL Server Linux container and stores database data on a persistent Railway volume.

Applications inside the same Railway project can connect through Railway private networking on port 1433, while external tools and applications can connect through Railway TCP Proxy.

The deployment uses SQL Server Developer edition by default, making it suitable for development, testing, integration, and non-production workloads.

Common Use Cases

• Backend databases for enterprise applications
• .NET and ASP.NET applications
• API and microservice data storage
• ERP and internal business systems
• Transactional application workloads
• Development and integration environments
• SQL Server compatibility testing
• Applications using JDBC, ODBC, or Microsoft SQL drivers

Dependencies for SQL Server Hosting

• Official Microsoft SQL Server container image
• Persistent Railway volume mounted at /var/opt/mssql
• Railway private networking
• Optional Railway TCP Proxy for external database access

Implementation Details

SQL Server communicates using the Tabular Data Stream protocol over:

TCP 1433

Persistent SQL Server files are stored under:

/var/opt/mssql

A Railway volume is attached to this directory so databases and SQL Server state remain available across redeployments and container restarts.

SQL Server Architecture on Railway

Application / Backend
        │
        │ Railway Private Network
        ▼
 SQL Server :1433
        │
        ▼
 Railway Volume
 /var/opt/mssql

External database clients can connect through Railway TCP Proxy:

SSMS / DBeaver / DataGrip
          │
          │ TCP Proxy
          ▼
    SQL Server :1433

SQL Server is not an HTTP service, so database access uses TCP rather than a standard Railway public HTTP domain.

Database Connection

Applications Inside Railway

Applications deployed inside the same Railway project should connect through Railway private networking.

A typical internal connection uses:

:1433

Using private networking keeps database traffic inside the Railway project and avoids unnecessary public exposure.

External Applications and Database Clients

For clients outside Railway, enable or use Railway TCP Proxy for port 1433.

Compatible tools include:

• SQL Server Management Studio
• DBeaver
• DataGrip
• Azure Data Studio
• sqlcmd
• .NET SqlClient
• JDBC-based applications
• ODBC-based applications
• Python database clients

The external hostname and port are provided by Railway TCP Proxy.

Connection Details

A SQL Server connection typically requires:

Host
Port
Username
Password
Database

The default administrator username is:

sa

Internal applications use port:

1433

External clients use the TCP Proxy port assigned by Railway.

A typical connection string may look like:

Server=HOST,PORT;User Id=sa;Password=PASSWORD;TrustServerCertificate=True;

Testing SQL Server

After connecting, verify the SQL Server version:

SELECT @@VERSION;

Check the current database:

SELECT DB_NAME();

Create a database:

CREATE DATABASE app;

Switch to it:

USE app;

Create a simple table:

CREATE TABLE users (
    id BIGINT IDENTITY(1,1) PRIMARY KEY,
    name NVARCHAR(255) NOT NULL,
    email NVARCHAR(255) UNIQUE,
    created_at DATETIME2 DEFAULT SYSUTCDATETIME()
);

Insert sample data:

INSERT INTO users (name, email)
VALUES ('Example User', 'user@example.com');

Query the table:

SELECT *
FROM users;

SQL Server Features

SQL Server is particularly useful for applications built around the Microsoft ecosystem, enterprise workloads, and systems that require compatibility with existing SQL Server databases and tools.

SQL Server vs Similar Relational Databases

SQL Server is often preferred for Microsoft-centric environments, enterprise applications, and workloads that already depend on SQL Server-specific tooling or compatibility.

PostgreSQL provides a highly extensible open-source alternative, while MySQL and MariaDB are widely used for web applications and MySQL-compatible software stacks.

Persistent Storage

A Railway volume is mounted at:

/var/opt/mssql

This keeps SQL Server data persistent across deployments.

Persistent state includes:

• User databases
• System databases
• Tables
• Indexes
• Stored procedures
• Users and permissions
• Transaction logs
• SQL Server configuration state

SQL Server Edition

This template uses the Developer edition by default.

Developer edition provides SQL Server features for development and testing but should not be treated as a production license.

For production usage, review Microsoft's SQL Server licensing requirements and choose an appropriate edition.

Changing the SQL Server Version

The template uses the Microsoft SQL Server container image provided through Microsoft Container Registry.

After deployment, you can change the SQL Server image version directly from the Railway service settings.

In Railway:

1. Open the SQL Server service.
2. Go to Settings.
3. Locate the container image/source configuration.
4. Change the image tag to the SQL Server version you want to use.
5. Redeploy the service.

For example, you may switch from a generic image reference to a version-specific image such as:

mcr.microsoft.com/mssql/server:2022-latest

Using a pinned version gives you more control over database upgrades and prevents unexpected major-version changes.

Before changing SQL Server versions, always verify compatibility and back up important databases.

Security and Access

For safer deployments:

• Keep SQL Server on Railway private networking whenever possible
• Use TCP Proxy only when external access is required
• Protect the sa password
• Create dedicated application logins instead of using sa for normal application access
• Apply the minimum permissions required by each application
• Review SQL Server edition and licensing requirements before production use

Getting Started After Deployment

1. Deploy the SQL Server template.
2. Wait for the database service to become available.
3. Retrieve the generated administrator password from the Railway service variables.
4. Connect through private networking for applications inside Railway.
5. Use Railway TCP Proxy for external database tools.
6. Connect using SQL Server Management Studio, DBeaver, DataGrip, sqlcmd, or your application.
7. Verify the database server with:

SELECT @@VERSION;

8. Create your application database, users, tables, indexes, and permissions.
9. If required, change the SQL Server image version from the Railway service settings after deployment.

Why Deploy SQL Server on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying SQL Server on Railway, you get persistent storage, private networking, optional external TCP access, and a flexible deployment that can be integrated with enterprise applications, APIs, backend services, and Microsoft-based technology stacks.