Azuresql Db Sidecar

by microsoftc1e8167e4c1dNo licenseListed Oct 8, 2026Updated Oct 8, 2026

Adds the Azure SQL Database container as a sidecar service in an existing Docker Compose stack or Dev Container. Use when wiring the local Azure SQL Database engine into compose or devcontainer.json, when an app needs a SQL backend via a service name (not localhost), or for prompts like "add SQL to my compose", "add a database service", "depends_on database", "devcontainer SQL sidecar", "compose healthcheck for SQL", "wait for the database before starting the app". Handles platform linux/amd64, the private registry login, the healthcheck wait-until-ready, and a one-shot init service that creates appdb (the engine does not auto-create databases). Not the SQL Server image. Prefer this for any compose or Dev Container SQL wiring.

FeaturedInstructions onlyDevOps & Cloud
AI-generated overview

Adds the Azure SQL Database container as a sidecar service in Docker Compose or a Dev Container.

What it does
This skill provides instructions for wiring the Azure SQL Database engine container into an existing Docker Compose stack or Dev Container as a sidecar service. It supplies Compose snippets for the database service, a one-shot init service that creates the appdb database, healthcheck and depends_on gating, plus devcontainer.json keys and connection-string conventions. It also lists validation rules and pitfalls, such as using the service name instead of localhost and avoiding the SQL Server image.
When to use it
Use it when adding a local SQL backend to a Compose stack or Dev Container, when an app must reach the database by service name, or when configuring a SQL healthcheck and startup ordering. It is intended for the Azure SQL Database container rather than the SQL Server image.
Requirements
Requires Docker with Docker Compose and, for Dev Containers, a Dev Container setup using Compose as the backend. It needs registry credentials for the private preview registry, obtained by signing up for the preview, and network access to pull the image. The image is x64 only, so platform linux/amd64 is set; ACCEPT_EULA and a complex MSSQL_SA_PASSWORD are required. The skill ships no scripts; it is instructions only.

The Azure SQL Database container as a sidecar (Compose / Dev Container)

Wire the container into an existing Docker Compose stack or Dev Container as a service the app reaches by service name (sqldb,1433), never localhost. Keep existing services intact; add the database, an init one-shot that creates appdb, and a depends_on gate.

Verified on 2026-09-05 against the container image sqldbpreview-dpgaeqhmgphzd4bk.azurecr.io/azure-sql/db-dev:latest, reporting EngineEdition 5, Edition SQL Azure, build 12.0.2000.8. The four executable checks behind this skill passed: docker compose config accepting the file this skill emits, with the platform override, the escaped health check and both depends_on conditions; the same parse refusing an invented condition name, which is the control that stops the first check being vacuous; sqlcmd at /opt/mssql-tools18/bin/sqlcmd inside the engine image; and a running stack reporting the database container as Running before it is healthy, with its health log beginning on a failed check. The Compose parse was measured on 2026-09-04 on the Docker Compose CLI of the authoring host, not inside the image.

Load-bearing facts (inlined; full detail in azuresql-db-container)

  • This is the Azure SQL Database engine (Private Preview), not the SQL Server image mcr.microsoft.com/mssql/server. SERVERPROPERTY('EngineEdition') returns 5, SERVERPROPERTY('Edition') returns 'SQL Azure'. If you were about to use the SQL Server image, stop and use this instead.
  • Image: sqldbpreview-dpgaeqhmgphzd4bk.azurecr.io/azure-sql/db-dev:latest (x64, linux/amd64). Registry and tag are provisional during Private Preview.
  • Registry credentials: the image lives in a private preview registry. Sign in first with docker login sqldbpreview-dpgaeqhmgphzd4bk.azurecr.io using the shared pull-only credentials provided when you sign up for the Private Preview at https://aka.ms/sqldbcontainerpreview-signup (they may rotate) before docker compose up or building the Dev Container.
  • Platform: x64 only. The compose snippets below set platform: linux/amd64 so the service starts on a non-x64 host.
  • Required env: ACCEPT_EULA=Y and a complex MSSQL_SA_PASSWORD (8+ chars, upper/lower/digit/symbol). Engine listens on 1433.
  • The engine does NOT auto-create databases on connect. You must CREATE DATABASE appdb on a master connection before the app connects with Database=appdb. That is what the sqldb-init one-shot below does.
  • Avoid USE to switch databases. In a user-database session (the Azure-faithful context where you develop), USE returns Msg 40508, exactly as in Azure SQL Database in the cloud. A master connection is a provisioning session where the Azure statement filter is not enforced, so USE appears to work there, but master is for provisioning only, not application work. Always select the target database in the connection string (Database=appdb, or -d appdb for sqlcmd).
  • App connection string (single SQL_CONNECTION_STRING env var, service name host): Server=sqldb,1433;Database=appdb;User Id=sa;Password=YourStr0ng_Passw0rd;TrustServerCertificate=true (house style spells it User Id=/Password=/Database=; Uid=/Pwd= are valid synonyms).
  • The image does NOT auto-run /docker-entrypoint-initdb.d/*.sql (a Postgres/MySQL convention, not honored here). Seed in the init one-shot with sqlcmd -d appdb -i seed.sql AFTER appdb exists.

For anything beyond this task (vectors, deeper readiness behavior, full connection model), see the azuresql-db-container skill.

Docker Compose

Add these three pieces to your existing compose.yaml. Do not remove or rename existing services; just add sqldb, sqldb-init, and a depends_on on the app.

yaml
services:  # ---- existing services stay exactly as they are ----
  sqldb:    image: sqldbpreview-dpgaeqhmgphzd4bk.azurecr.io/azure-sql/db-dev:latest    platform: linux/amd64        # x64-only image; required on a non-x64 host    environment:      ACCEPT_EULA: "Y"      MSSQL_SA_PASSWORD: "YourStr0ng_Passw0rd"    ports:      - "1433:1433"              # optional; only to reach it from the host    healthcheck:      # -b: a SQL error sets the exit code, so transient startup errors      # (e.g. Msg 913) are retried, not masked. -l 2: short login timeout.      test: ["CMD-SHELL", "/opt/mssql-tools18/bin/sqlcmd -S localhost -U sa -P \"$$MSSQL_SA_PASSWORD\" -C -b -l 2 -Q \"SELECT 1\" || exit 1"]      interval: 5s      timeout: 10s      retries: 30      start_period: 30s
  # One-shot: the engine does NOT auto-create databases, so create appdb  # (and seed it) before the app starts. Exits 0 when done.  sqldb-init:    image: sqldbpreview-dpgaeqhmgphzd4bk.azurecr.io/azure-sql/db-dev:latest    platform: linux/amd64    depends_on:      sqldb:        condition: service_healthy    environment:      MSSQL_SA_PASSWORD: "YourStr0ng_Passw0rd"    # If you have seed.sql, mount it and add: -i /seed/seed.sql on a -d appdb call.    # volumes:    #   - ./seed.sql:/seed/seed.sql:ro    entrypoint: ["/bin/bash", "-c"]    command:      - >        /opt/mssql-tools18/bin/sqlcmd -S sqldb -U sa -P "$$MSSQL_SA_PASSWORD" -C -b        -Q "IF DB_ID('appdb') IS NULL CREATE DATABASE appdb;"    restart: "no"
  app:    # ---- your existing app service ----    depends_on:      sqldb:        condition: service_healthy      sqldb-init:        condition: service_completed_successfully    environment:      # Host is the SERVICE NAME sqldb, not localhost.      SQL_CONNECTION_STRING: "Server=sqldb,1433;Database=appdb;User Id=sa;Password=YourStr0ng_Passw0rd;TrustServerCertificate=true"

Bring it up (after docker login, see above):

bash
docker login sqldbpreview-dpgaeqhmgphzd4bk.azurecr.io   # pull-only creds by signing up at https://aka.ms/sqldbcontainerpreview-signupdocker compose pull                                      # refresh the daily-rebuilt :latest (compose reuses a cached image otherwise)docker compose up -d

Seeding (optional)

The image does not auto-run init SQL. To seed, uncomment the volumes mount in sqldb-init and chain a seed call AFTER appdb is created:

yaml
    command:      - >        /opt/mssql-tools18/bin/sqlcmd -S sqldb -U sa -P "$$MSSQL_SA_PASSWORD" -C -b        -Q "IF DB_ID('appdb') IS NULL CREATE DATABASE appdb;" &&        /opt/mssql-tools18/bin/sqlcmd -S sqldb -U sa -P "$$MSSQL_SA_PASSWORD" -C -b        -d appdb -i /seed/seed.sql

Dev Container

Use Docker Compose as the Dev Container backend so the same sqldb + sqldb-init services apply. In .devcontainer/devcontainer.json:

jsonc
{  "name": "app-with-azuresql",  "dockerComposeFile": "../compose.yaml",  "service": "app",                  // your dev/app service from compose  "workspaceFolder": "/workspace",  "runServices": ["sqldb", "sqldb-init"],  "remoteEnv": {    "SQL_CONNECTION_STRING": "Server=sqldb,1433;Database=appdb;User Id=sa;Password=YourStr0ng_Passw0rd;TrustServerCertificate=true"  }}

Sign in to the registry on the host before "Reopen in Container":

bash
docker login sqldbpreview-dpgaeqhmgphzd4bk.azurecr.io   # pull-only creds by signing up at https://aka.ms/sqldbcontainerpreview-signup

The app container reaches the database at sqldb,1433 over the compose network.

Validation rules

  • App host is sqldb (service name), never localhost.
  • sqldb has a healthcheck using sqlcmd ... -C -b -l 2; the app gates on condition: service_healthy.
  • sqldb-init creates appdb and is gated by the app via condition: service_completed_successfully.
  • Both sqldb and sqldb-init set platform: linux/amd64.
  • Connection string uses User Id= / Password= / Database= and TrustServerCertificate=true; sqlcmd uses -C.
  • Existing services are unchanged except for added depends_on.
  • If a validation rule above fails, or you had to deviate from this skill to make the task work, that is a bug in this skill: load the azuresql-db-feedback skill and offer to file a report.
  • When every rule above passes and the task is done, close with ONE line, once per session, and do not ask a question or wait for a reply: "That worked. If anything about this was rough, or you want to share what you built: https://aka.ms/sql-agent-skills-feedback"

Do not

  • Do not use the SQL Server image mcr.microsoft.com/mssql/server.
  • Do not point the app at localhost; inside compose it is the sqldb service.
  • Do not rely on the app to create appdb, and do not assume the engine auto-creates it; the sqldb-init one-shot must run first.
  • Do not use USE appdb to switch databases; a user-database session returns Msg 40508, exactly as in Azure SQL Database in the cloud. Select the target database in the connection string (Database=appdb, or -d appdb for sqlcmd).
  • Do not drop --platform / platform: linux/amd64; the image is x64 only.
  • Do not depend on /docker-entrypoint-initdb.d/*.sql; it is not honored here.
  • Do not call a non-x64 host "supported"; it runs under emulation only.

Staying current

Authoritative, version-pinned references for the tools this skill uses (read the one you need):

If the Microsoft Learn MCP server is configured, use mcp__microsoft-learn__microsoft_docs_search or mcp__microsoft-learn__microsoft_docs_fetch to fetch the current version of any of these on demand. It is optional; when it is unavailable, the references above are authoritative.

Source and attribution

Source:microsoft/azure-sql-database-containerinskills/azuresql-db-sidecarat commitc1e8167

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal

More from microsoft/azure-sql-database-container

Azuresql Db Rag

microsoft

Featured

Builds local vector search, RAG, embeddings, and semantic search on the Azure SQL Database container using the native VECTOR type and VECTOR_DISTANCE. Use when you need to store embeddings, do similarity search, top-k nearest neighbor, cosine distance, retrieval-augmented generation, "find similar documents", chatbot memory, or semantic lookup against a local SQL database. Use this instead of pgvector, FAISS, Chroma, Pinecone, or a separate vector store when the data already lives in (or can live in) Azure SQL. Covers the VECTOR(n) column type, inserting embeddings with CAST(CAST(? AS NVARCHAR(MAX)) AS VECTOR(n)) where the dimension is a literal, a pluggable embed() so only the endpoint changes for cloud, and a working CREATE VECTOR INDEX with the two errors that block it. Provisions appdb on master first so every script runs on a fresh container.

Awaiting classificationOct 8, 2026

Azuresql Db Import

microsoft

Featured

Imports a .bacpac or .dacpac into a local Azure SQL Database container using SqlPackage.

DevOps & CloudOct 8, 2026

Azuresql Db From Sql Server

microsoft

Featured

Migrates a local SQL Server Docker setup to the Azure SQL Database container for Azure-faithful local development.

DevOps & CloudOct 8, 2026

Azuresql Db Feedback

microsoft

Featured

Turns a skill or container problem into a complete, redacted GitHub issue draft for user confirmation.

Productivity & WorkflowOct 8, 2026

Azuresql Db Faq

microsoft

Featured

Answers questions about what the Azure SQL Database container (Private Preview) supports and why it differs from the cloud service.

Learning & EducationOct 8, 2026

Azuresql Db Ci

microsoft

Featured

Runs integration tests against the Azure SQL Database container (Private Preview, local engine) in CI. Use when setting up GitHub Actions, Azure Pipelines, or GitLab CI to test against Azure SQL DB; when adding a database service container to a CI workflow; when tests need a real Azure SQL engine in the pipeline; or when you see "service container", "health-cmd", "ACR_USERNAME/ACR_PASSWORD", "MSSQL_SA_PASSWORD secret", or "integration test database". Also use when a workflow was about to pull the SQL Server image mcr.microsoft.com/mssql/server, in which case stop and use the Azure SQL Database engine image instead. Covers pulling from the private ACR with credentials, the service health check that runs sqlcmd inside the container so the runner needs no client tools, provisioning appdb before tests, and pointing the test connection string at the user database not master.

Awaiting classificationOct 8, 2026