Azure SQL Database container packages the Azure SQL Database engine so developers can run it locally in a container while building and testing applications before deploying to Azure. It is intended for local development and continuous integration, with catalogue add-ons helping coding agents work with the container.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/microsoft/azure-sql-database-container/azuresql-db-local-to-cloudnpx skills add microsoft/azure-sql-database-container --skill azuresql-db-local-to-cloudgit clone --depth 1 https://github.com/microsoft/azure-sql-database-containerWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/microsoft/azure-sql-database-container/azuresql-db-local-to-cloud)<a href="https://agentmods.dev/skills/microsoft/azure-sql-database-container/azuresql-db-local-to-cloud"><img src="https://agentmods.dev/badge/skills/microsoft/azure-sql-database-container/azuresql-db-local-to-cloud.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00185 | $0.03473 |
| Opus 5 | $0.00093 | $0.01736 |
| Sonnet 5 | $0.00037 | $0.00695 |
| Haiku 4.5 | $0.00018 | $0.00347 |
Grade A, and why
azuresql-db-local-to-cloud scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured today.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 264 lines — stays where its author put it; the contents beside it link to each section on GitHub.
From the Azure SQL Database container to Azure SQL Database: same code, local to cloud
Build and test against the local container, then deploy the same application code to Azure SQL Database in the cloud. Only the connection string changes. Nothing else.
This works because the local container is the Azure SQL Database engine, not
the SQL Server image. SELECT SERVERPROPERTY('EngineEdition') returns 5
and SERVERPROPERTY('Edition') returns 'SQL Azure', the same as the cloud. So
the SQL surface your code depends on is the same in both places.
The one rule
Do not change application code between local and cloud. The application reads
its connection string from a single environment variable, SQL_CONNECTION_STRING.
Local development sets it to the container; cloud deployment sets it to the Azure
SQL server. Same binaries, same queries, same schema.
If you find yourself editing queries, drivers, or schema to "make it work in Azure", stop: that is a bug. The only thing that legitimately differs is the connection string (and, with it, the auth method).
The single env var, two values
Standardize on SQL_CONNECTION_STRING. House style spells the keywords
User Id= / Password= / Database= so every example matches. Uid= and
Pwd= are documented SqlClient synonyms and work too. ODBC strings are a
separate grammar and use Uid= / Pwd= as their own keywords.
Local (container, SA auth):
Server=localhost,1433;Database=appdb;User Id=sa;Password=YourStr0ng_Passw0rd;TrustServerCertificate=true
Cloud (Azure SQL Database, Microsoft Entra auth):
Server=your-server.database.windows.net,1433;Database=appdb;Authentication=Active Directory Default;Encrypt=true
Note what stays identical: Database=appdb, the table names, the parameterized
SQL. Only Server, the auth fields, and TLS posture move.
Local SA auth vs cloud Entra auth (why, not just how)
Local: the container is provisioned with one bootstrap login, sa, set via the
MSSQL_SA_PASSWORD environment variable. There is no identity provider required
in front of a container on your laptop, so password auth over a trusted
self-signed cert (TrustServerCertificate=true) is the pragmatic local default.
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- today Changed · +6 lines aba2faac5279
- 5d ago First seen · 258 lines · 185 tokens per session scan A 1ab8a4f98012
azuresql-db-local-to-cloud is a skill published in the GitHub repository microsoft/azure-sql-database-container (17 stars, last pushed today), licensed MIT. It adds 185 tokens to every session and 3,473 once invoked, about $0.0009 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
google-cloud-storage-fuse
Mounts Cloud Storage buckets as a POSIX file system with Cloud Storage FUSE (gcsfuse). Use when interacting with gcsfuse: decide whether FUSE, native gs:// reads, or Filestore/Managed Lustre fits a workload, deploy tuned mounts on GKE, Compute Engine, or Cloud Run, enable and size file, stat, and list caches, tune…
cloud-databases-onboarding
Guides users through discovering their database requirements, recommends a Google Cloud database based on a recommendation matrix, and assists in database creation. Use when a user asks 'What database service should I use?', 'Help me pick a database', or when a user wants to create a new database on Google Cloud.…
cloud-sql-basics
This file generates or explains Cloud SQL resources. Use this file when the user asks to create a Cloud SQL instance or database for MySQL, PostgreSQL, or SQL Server. Cloud SQL manages third-party MySQL, PostgreSQL, and SQL Server instances as resources in Cloud SQL. For example, when Cloud SQL creates an open-source…
azure-resource-manager-mysql-dotnet
Azure MySQL Flexible Server SDK for .NET. Database management for MySQL Flexible Server deployments. Use for creating servers, databases, firewall rules, configurations, backups, and high availability. Triggers: "MySQL", "MySqlFlexibleServer", "MySQL Flexible Server", "Azure Database for MySQL", "MySQL database…
azure-mgmt-mongodbatlas-dotnet
Manage MongoDB Atlas Organizations as Azure ARM resources using Azure.ResourceManager.MongoDBAtlas SDK. Use when creating, updating, listing, or deleting MongoDB Atlas organizations through Azure Marketplace integration. This SDK manages the Azure-side organization resource, not Atlas clusters/databases directly.
azure-resource-manager-redis-dotnet
Azure Resource Manager SDK for Redis in .NET. Use for MANAGEMENT PLANE operations: creating/managing Azure Cache for Redis instances, firewall rules, access keys, patch schedules, linked servers (geo-replication), and private endpoints via Azure Resource Manager. NOT for data plane operations (get/set keys, pub/sub) …