Azure Cost Estimation
tsdevstack is free and open source. All costs on this page are paid directly to Microsoft Azure. There is no bill from tsdevstack and there never will be.
These are estimates based on published Azure pricing as of July 2026 in a US region (East US). Actual costs depend on your region, traffic, and any pricing changes by Microsoft. Always verify with the official pricing pages linked at the bottom.
The AI buildout is squeezing server hardware supply, and that is expected to reach cloud list prices in the second half of 2026. As of July 2026 the Azure rates on this page are unchanged, including Container Apps consumption at $0.000024/vCPU-second and $0.000003/GiB-second.
Server memory contract prices rose sharply through the first half of 2026, and there is typically a 6 to 9 month lag before that shows up in cloud pricing, with forecasts pointing to roughly 5-10% general increases. The most exposed lines here are PostgreSQL Flexible Server and Managed Redis, which are priced off provisioned memory, followed by App Service plans. Front Door base fees are the least exposed. If you are budgeting past Q3 2026, add a 10% buffer on the database and cache lines.
What Gets Deployed
A typical tsdevstack project (3 NestJS backends + 1 Next.js frontend) creates these billable resources on Azure:
You can override CPU, memory, instance counts, database tier, Redis tier, disk size, App Service SKU, and Front Door tier in infrastructure.json. See Service Configuration for all available options.
Standard vs Premium
The biggest cost decision on Azure is the Front Door tier:
All scenarios below show Standard pricing. Add ~$377.50/month for Premium. (Base fees verified against the Azure Retail Prices API, July 2026.)
Scenario 1 — Development (Scale-to-Zero, Standard)
Backend services set to minInstances: 0 (default on Azure). Kong and Next.js always on via App Service. Assumed traffic: ~1,000 requests/day (testing only).
Cold starts after scale-to-zero: 2-5 seconds. Container Apps use KEDA HTTP scaling — no wake-up mechanisms needed.
Scenario 2 — Production (Always-On, Single Instance, Standard)
All services with minInstances: 1. Assumed traffic: ~100,000 requests/day (3M/month).
Container Apps idle billing is the reason this stays moderate: a minInstances: 1 replica with no requests bills vCPU at $0.000003/sec rather than the active $0.000024/sec, and the first 180,000 vCPU-seconds and 360,000 GiB-seconds each month are free. Upgrading App Service to S1 (~$69/plan) enables auto-scaling for Kong and Next.js.
Scenario 3 — Production Under Load (3 Instances, 24/7, Standard)
Services auto-scale to 3 replicas average. App Service upgraded to S1 for auto-scaling. Assumed traffic: ~10M requests/day (300M/month).
At moderate traffic these replicas bill at $0.000003/vCPU-sec. Once they are serving continuously they bill at $0.000024/vCPU-sec, the same active rate as Cloud Run, which is why this line jumps from ~$39 to ~$250. Front Door's $0.011 per 10,000 requests is the other dominant line at this volume. Earlier versions of this page listed these at ~$15-40 and ~$45-65, which was far too low.
At this scale, consider Azure Reservations for App Service and PostgreSQL (up to 40% savings with 1-year commitment).
What Drives the Cost
How to Reduce Costs
- Use Standard Front Door unless you need Private Link or managed WAF rulesets — saves $377.50/month
- Stay on B1 App Service for development — upgrade to S1 only when you need auto-scaling
- Keep
minInstances: 0on Container Apps in development — accept 2-5s cold starts - Use
B_Standard_B1msfor development databases — upgrade only when needed - Azure Reservations — 1-year commitment saves up to 40% on App Service and PostgreSQL
Unlike GCP, which defaults to minInstances: 1, and AWS, which has no scale-to-zero at all, Azure's service default is minInstances: 0. That applies to production too, so unless you set it explicitly your production backend services will scale to zero and every cold request pays the 2-5s startup penalty, plus database connection pool warmup on top.
Set it per environment in .tsdevstack/infrastructure.json:
Kong is unaffected: it is clamped to at least 1 on all providers regardless of configuration.
Override any default in .tsdevstack/infrastructure.json:
See Service Configuration for all available options.