Running SQL Server in Docker for Local Dev

Why Run SQL Server in Docker?

When developing a .NET application that uses SQL Server, the traditional approach is to install SQL Server directly onto your development machine. While this works perfectly well, it also means installing database services, management tools and supporting components that you may not always need.

Docker provides a much cleaner alternative.

Instead of installing SQL Server directly onto Windows, you can run it inside a Docker container. The database is then isolated from the rest of your development environment while still being accessible to applications running on your machine.

This is particularly useful when working on multiple projects that require different database configurations. Containers can be created, stopped, removed and recreated without affecting the underlying operating system.

It also makes it much easier to give another developer the same development environment.

Getting the SQL Server Docker Image

Microsoft provides an official SQL Server container image that can be used with Docker.

Before getting started, you will need Docker Desktop installed and running on your development machine.

Once Docker is available, the SQL Server image can be downloaded using the Docker command line.

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

This downloads the SQL Server 2022 image from Microsoft's container registry.

The image itself contains everything required to run SQL Server. You don't need to install SQL Server separately on your development machine.

Creating the SQL Server Container

Once the image has been downloaded, we can create a container from it.

A simple example is:

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=YourStrongPassword123!" -p 1433:1433 --name sqlserver -d mcr.microsoft.com/mssql/server:2022-latest

There are several important parts to this command.

The ACCEPT_EULA environment variable tells SQL Server that the licence agreement has been accepted.

The MSSQL_SA_PASSWORD variable specifies the password for the SQL Server sa account. You should use a strong password for your own development environment rather than copying the example above.

The -p 1433:1433 option maps port 1433 on your development machine to port 1433 inside the container.

Finally, --name sqlserver gives the container an easy-to-remember name.

The -d option runs the container in the background, allowing you to continue using the terminal.

Checking That SQL Server Is Running

After creating the container, you can check its status using Docker.

docker ps

You should see the SQL Server container listed along with its current status and port mapping.

If the container has stopped unexpectedly, you can inspect its output using:

docker logs sqlserver

This is particularly useful when troubleshooting configuration or startup problems.

If SQL Server has successfully started, the logs will indicate that the database engine is ready to accept connections.

Connecting to SQL Server

Once SQL Server is running, you can connect to it using SQL Server Management Studio, Azure Data Studio or another SQL Server-compatible database tool.

For a local Docker container, the server name can normally be:

localhost,1433

You can then authenticate using SQL Server authentication with the sa account and the password you specified when creating the container.

From the point of view of your development tools, SQL Server is effectively running locally even though the database engine is actually running inside Docker.

Connecting from a .NET Application

One of the biggest advantages of this setup is that your .NET application can connect to the container using a normal SQL Server connection string.

For example:

Server=localhost,1433;Database=MyApplication;User Id=sa;Password=YourStrongPassword123!;TrustServerCertificate=True;

The TrustServerCertificate=True option is commonly useful in local development because the SQL Server container may not have a certificate configured that your development machine trusts.

For a production environment, however, you should use an appropriate certificate and secure authentication configuration rather than simply copying a development connection string.

Using Entity Framework Core

If your application uses Entity Framework Core, the Docker-based SQL Server instance can be used in exactly the same way as a normally installed SQL Server instance.

For example, your connection string could be stored in appsettings.Development.json.

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=localhost,1433;Database=MyApplication;User Id=sa;Password=YourStrongPassword123!;TrustServerCertificate=True;"
  }
}

Your application can then register the SQL Server database provider in the usual way.

builder.Services.AddDbContext<ApplicationDbContext>(options =>
    options.UseSqlServer(
        builder.Configuration.GetConnectionString("DefaultConnection")));

The important point is that your application doesn't really care that SQL Server is running inside Docker. It simply connects to a SQL Server endpoint.

Keeping Your Database Data

There is one important consideration when using containers.

A Docker container is designed to be disposable. If you remove the container without storing the SQL Server data somewhere outside the container, you can potentially lose your databases.

For local development, it is therefore a good idea to use a Docker volume.

A volume allows the SQL Server data files to exist independently of the container itself.

For example:

docker volume create sqlserver-data

The container can then be created using the volume:

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=YourStrongPassword123!" -p 1433:1433 --name sqlserver -v sqlserver-data:/var/opt/mssql -d mcr.microsoft.com/mssql/server:2022-latest

The /var/opt/mssql directory is where SQL Server stores its data inside the Linux-based container.

With the volume attached, you can remove and recreate the container without automatically losing the database files.

Starting and Stopping SQL Server

One of the nicest things about using Docker for local development is how easy it is to start and stop SQL Server.

To stop the container:

docker stop sqlserver

To start it again:

docker start sqlserver

There is no need to reinstall anything or configure SQL Server again.

You can also see all containers, including stopped containers, with:

docker ps -a

This makes Docker particularly convenient when you only need SQL Server while working on a particular project.

Using Docker Compose

For anything beyond a simple experiment, Docker Compose can make the setup even easier.

Instead of remembering a long docker run command, you can define the SQL Server configuration in a docker-compose.yml file.

For example:

services:
  sqlserver:
    image: mcr.microsoft.com/mssql/server:2022-latest
    container_name: sqlserver
    environment:
      ACCEPT_EULA: "Y"
      MSSQL_SA_PASSWORD: "YourStrongPassword123!"
    ports:
      - "1433:1433"
    volumes:
      - sqlserver-data:/var/opt/mssql

volumes:
  sqlserver-data:

You can then start SQL Server with:

docker compose up -d

And stop it with:

docker compose down

This becomes particularly useful when your application eventually needs other services such as Redis, Elasticsearch or additional databases.

The entire development environment can be described as configuration rather than a collection of manual installation instructions.

A Clean Development Environment

One of the biggest benefits of this approach is that it keeps your development machine clean.

Rather than having SQL Server installed as a permanent Windows service, Docker allows the database to exist only when you need it.

If a project requires a different version of SQL Server, you can run another container using a different image tag.

You can also completely remove a development environment when a project has finished.

This makes Docker particularly useful for developers who regularly work on multiple applications.

Docker Is Not Just for Production

Docker is often associated with deploying applications to cloud environments, but it is equally useful during development.

Running SQL Server in Docker gives you a repeatable development environment that can be recreated quickly on another machine.

For a .NET developer, this can be especially useful when combined with ASP.NET Core, Entity Framework Core and other containerised services.

Instead of spending time installing and configuring dependencies, you can describe the environment in Docker configuration and get back to writing code.

Conclusion

Running SQL Server in Docker is a simple and practical way to create a local database environment without installing SQL Server directly onto your development machine.

Containers make it easy to start and stop SQL Server, recreate environments and keep database dependencies isolated from the operating system. Adding Docker volumes also ensures that your development databases can survive container recreation.

For .NET developers using SQL Server, Entity Framework Core and ASP.NET Core, Docker provides a clean and repeatable development workflow.

Once you become comfortable with running your database in a container, it becomes much easier to build complete development environments where the application, database and supporting services can all be started with a few commands.