# tsdevstack > Full-stack, cloud-native TypeScript framework for production microservices ## Docs - [What is tsdevstack?](/docs/introduction/what-is-tsdevstack.md): tsdevstack is the first Infrastructure as Framework — a full-stack, cloud-native, AI-native TypeScript framework where infrastructure isn't something you build alongside your app, it's a built-in feature of the framework itself. You don't write Terraform. You don't configure gateways. You don't set up CI/CD pipelines. The framework generates, manages, and deploys all of it. You write application code — tsdevstack handles everything else. ## Others - [Agent knowledge is a trigger problem, not a writing problem](/blog/agent-knowledge-is-a-trigger-problem.md): I put everything the agent needed into an MCP resource and it never got read. The four channels for teaching an agent your framework are not four kinds of content. They are four trigger conditions, each with a different price. - [Agentic loops don't fix lying agents](/blog/agentic-loops-dont-fix-lying-agents.md): Loop engineering is the current answer to unreliable coding agents. But a loop is only as good as its verifier, and I have the receipts for what slips through. - [Cloud Run private networking without a VPC Connector](/blog/cloud-run-private-networking-without-a-vpc-connector.md): Direct VPC Egress + Cloud DNS + Private Google Access gets you internal service-to-service calls on Cloud Run for ~$0.20/month instead of $14-30. - [Democratizing professional cloud infrastructure](/blog/democratizing-professional-cloud-infrastructure.md): The cloud the serious companies use is closer than you think. Vibe coding gets you a prototype and drops you at the edge of the hard part. Here is what closed the gap between something that runs on your machine and something deployed, secure, on real infrastructure. - [Getting a production WAF out of Azure Front Door Standard](/blog/getting-a-production-waf-out-of-azure-front-door-standard.md): Front Door Standard caps a WAF at 100 custom rules for $35 a month. What that covers, and when Premium's $330 tier earns the extra $295. - [I built a TypeScript framework that generates your entire cloud infrastructure](/blog/i-built-a-typescript-framework-that-generates-your-entire-cloud-infrastructure.md): tsdevstack generates Terraform, Docker, Kong routes, CI/CD, secrets, and observability across GCP, AWS, and Azure from one TypeScript config. - [IaC, FdI, IaF: three ways a codebase becomes infrastructure](/blog/iac-fdi-iaf-three-ways-a-codebase-becomes-infrastructure.md): Frameworks defining infrastructure is suddenly a live idea, and the terms are blurring. Here is a clean taxonomy of the three approaches and what each one trades away. - [Blog](/blog/index.md): Posts on cloud infrastructure, TypeScript microservices, and the tooling behind tsdevstack. - [Infrastructure as Framework: A New Abstraction for Cloud Deployment](/blog/infrastructure-as-framework-a-new-abstraction-for-cloud-deployment.md): A new abstraction between Infrastructure as Code and PaaS. One TypeScript config that deploys to GCP, AWS, or Azure without rewriting. - [MCP annotations are a UX layer, not a security layer](/blog/mcp-annotations-are-a-ux-layer-not-a-security-layer.md): Tool annotations like readOnlyHint are server-declared hints, not enforcement. Treating them as permissions is a category error the spec warns against. - [Migrating off AWS App Runner before the April 30 deadline](/blog/migrating-off-aws-app-runner-before-the-april-30-deadline.md): AWS is closing App Runner to new customers on April 30, 2026. Notes from a production Next.js migration to standard ECS Fargate, and why I skipped Express Mode. - [API Keys](/docs/authentication/api-keys.md): API keys give machines access to your API without a user login. A partner, an integration or a script sends a key in the x-api-key header, and the gateway checks it before anything reaches your services. Keys are not tied to users. Each key belongs to a named consumer, for example acme-corp: whoever you issued it to. Admins create, limit, rotate and revoke keys at runtime through the auth-service admin API. Changes take effect on the next request, with no redeploy. This page covers the full auth template (the auth-service that init creates). Projects without it can still use keys by writing them to Redis themselves; see Managing keys without the auth service. - [JWT Tokens](/docs/authentication/jwt-tokens.md): tsdevstack uses JSON Web Tokens (JWT) for stateless authentication. Tokens are issued by the auth service and validated by Kong before requests reach your backend services. - [Managing Users](/docs/authentication/managing-users.md): How to get from "I just deployed" to "I'm logged in as an admin", and how to handle users after that, locally and in the cloud. There is no admin panel. Users, roles and passwords are managed through the auth-service API, with curl, a REST client, or your own admin UI built on the generated client. - [Authentication Overview](/docs/authentication/overview.md): tsdevstack provides a complete authentication system out of the box, handling JWT tokens, session management, and protected routes. - [Protected Routes](/docs/authentication/protected-routes.md): tsdevstack provides guards and decorators for protecting API endpoints. Kong handles token validation at the gateway level, while AuthGuard provides additional protection and user context in your services. - [Roles](/docs/authentication/roles.md): Every user has one system role and any number of custom roles. Both travel in the access token, and any NestJS service can restrict an endpoint to them with @Roles(). This page covers the full auth template (the auth-service that init creates). The @Roles() decorator itself lives in @tsdevstack/nest-common and works with any auth-service that puts the same claims in its tokens. - [Session Management (Next.js)](/docs/authentication/session-management.md): This page covers cookie-based session management for Next.js frontend applications. The Next.js app acts as a Backend-for-Frontend (BFF), storing tokens in HTTP-only cookies rather than localStorage for better XSS protection. - [DTO Generation](/docs/building-apis/dto-generation.md): Generate type-safe TypeScript clients and NestJS DTOs from your OpenAPI specifications. This enables shared contracts between services with full validation and documentation support. - [Gateway Routing](/docs/building-apis/gateway-routing.md): Kong Gateway routes requests to your backend services based on OpenAPI specs. Routes are generated from your code, so you rarely need to configure routing manually. The OpenAPI document is the single source of truth: an operation that is not in it is not reachable through the gateway. - [OpenAPI Decorators](/docs/building-apis/openapi-decorators.md): NestJS decorators document your API endpoints. tsdevstack uses these OpenAPI specs to generate Kong gateway routes automatically. - [Swagger UI and API Documentation](/docs/building-apis/swagger-docs.md): Your API documentation is generated automatically from your code. This guide explains how to access, use, and generate the documentation. - [Docker Overrides](/docs/customization/docker-overrides.md): For local development, Docker Compose runs infrastructure services (Kong gateway, PostgreSQL, Redis, monitoring tools). Your backend services (auth-service, bff-service, etc.) run natively via npm for faster iteration. Use docker-compose.user.yml to add extra infrastructure or override Docker settings without modifying framework-managed files. - [Custom Email Provider](/docs/customization/email-provider.md): The framework uses Resend for production emails and a console logger for local development. You can replace either with any email service — SendGrid, Mailgun, Postmark, Amazon SES, etc. The NotificationService API stays the same. Only the underlying delivery mechanism changes. - [Escape Hatches](/docs/customization/escape-hatches.md): The framework provides sensible defaults and a merge-based customization system for most needs. But sometimes you need full control. Escape hatches let you bypass framework automation entirely when the standard patterns do not fit. - [Framework Files vs User Files](/docs/customization/framework-files.md): The framework uses a layered file system that separates auto-generated configuration from your customizations. This pattern keeps your changes safe during upgrades while allowing the framework to evolve its defaults. - [Kong Customization](/docs/customization/kong-customization.md): The framework generates Kong Gateway configuration automatically, but you can customize it for your specific needs. This guide explains the configuration file system and how to add your own settings. - [Kong Plugins](/docs/customization/kong-plugins.md): Kong ships with a long list of bundled plugins (CORS, rate limiting, request size limits, caching, and so on); you enable those in kong.user.yml without any extra setup, see Kong Customization. This page is about the other case: your own Lua plugin, baked into the gateway image. - [WAF Customization](/docs/customization/waf-customization.md): tsdevstack ships with WAF (Web Application Firewall) protection enabled by default on all three providers. This page explains what's included, how to diagnose issues, and how to add your own rules. - [Async Messaging](/docs/features/async-messaging.md): Inter-service event broadcasting via Redis Streams. Publish events from one service, and all subscribing services receive every message independently — no new infrastructure required. - [MCP Server](/docs/features/mcp-server.md): tsdevstack includes a built-in Model Context Protocol (MCP) server that exposes CLI commands and project context to AI agents. This gives tools like Claude Code, Claude Desktop, Cursor, and VS Code Copilot an understanding of your project structure, service configuration, and available workflows — so they can assist you accurately instead of guessing. - [Object Storage](/docs/features/object-storage.md): tsdevstack provides unified object storage across all cloud providers. Add a bucket, import StorageModule, and your code works identically on local RustFS, AWS S3, GCP Cloud Storage, and Azure Blob Storage. - [Observability](/docs/features/observability.md): tsdevstack includes a complete observability stack: structured logging, Prometheus metrics, distributed tracing, and health checks. All features are enabled by default when you import ObservabilityModule. - [Scheduled Jobs](/docs/features/scheduled-jobs.md): CRON-based scheduled jobs that invoke HTTP endpoints on your services. Configured in infrastructure.json, deployed via CLI, with provider-specific infrastructure generated automatically. - [Installation](/docs/getting-started/installation.md) - [Prerequisites](/docs/getting-started/prerequisites.md): Before installing tsdevstack, make sure you have the following: - [Project Structure](/docs/getting-started/project-structure.md): tsdevstack uses a monorepo structure where all your applications, packages, and infrastructure live together. This makes it easy to share code, manage dependencies, and deploy consistently. - [Quick Start](/docs/getting-started/quick-start.md): Get from zero to production in an hour. - [Your First App](/docs/getting-started/your-first-app.md): Let's add a NestJS service and see it running. - [Infrastructure Architecture](/docs/infrastructure/architecture.md): This page covers the cloud deployment architecture. For conceptual architecture and request flows, see Architecture Overview. - [CI/CD Setup](/docs/infrastructure/cicd-setup.md): Set up automated deployments using GitHub Actions. - [Domain Setup](/docs/infrastructure/domain-setup.md): Configuring domains for tsdevstack deployments. - [Environments](/docs/infrastructure/environments.md): tsdevstack supports multiple deployment environments. Each environment is completely isolated with its own cloud project/account. - [AWS Account Setup](/docs/infrastructure/providers/aws/account-setup.md): Setting up AWS for tsdevstack deployments. AWS requires separate accounts per environment for proper isolation. Why separate accounts? Secrets Manager isolation, billing separation, resource name isolation, and impossible cross-environment access. - [AWS Architecture](/docs/infrastructure/providers/aws/architecture.md): What gets deployed when you run infra:deploy on AWS and how traffic flows through the system. - [AWS CI/CD](/docs/infrastructure/providers/aws/cicd.md): Set up OIDC (OpenID Connect) federation for GitHub Actions to authenticate with AWS without storing long-lived access keys. For generating workflow files and general CI/CD setup, see CI/CD Setup. - [AWS Cost Estimation](/docs/infrastructure/providers/aws/cost-estimation.md): These are estimates based on published AWS pricing as of July 2026 in a US region (us-east-1). Actual costs depend on your region, traffic, and any pricing changes by Amazon. Always verify with the official pricing pages linked at the bottom. - [AWS DNS & Domains](/docs/infrastructure/providers/aws/dns-and-domains.md): Provider-specific DNS configuration and SSL certificate setup for AWS deployments. - [Amazon Web Services (AWS)](/docs/infrastructure/providers/aws/index.md): tsdevstack on AWS uses ECS Fargate for all containerized services (backends, Next.js frontends, workers), RDS PostgreSQL for databases, and ElastiCache for Redis. CloudFront provides CDN and edge caching, with AWS WAF for security. Backend services run in private subnets and are reachable only inside the VPC: Kong calls them directly through Cloud Map service discovery, the same private model as on GCP and Azure. Fargate has no scale-to-zero, so every service keeps at least one task running. The architecture uses ~45 Terraform resources. - [Azure Account Setup](/docs/infrastructure/providers/azure/account-setup.md): Setting up Azure for tsdevstack deployments. Each environment requires its own subscription for isolation. - [Azure Architecture](/docs/infrastructure/providers/azure/architecture.md): What gets deployed when you run infra:deploy on Azure and how traffic flows through the system. - [Azure CI/CD](/docs/infrastructure/providers/azure/cicd.md): Set up OIDC (OpenID Connect) federation for GitHub Actions to authenticate with Azure without storing client secrets. For generating workflow files and general CI/CD setup, see CI/CD Setup. - [Azure Cost Estimation](/docs/infrastructure/providers/azure/cost-estimation.md): 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. - [Azure DNS & Domains](/docs/infrastructure/providers/azure/dns-and-domains.md): Provider-specific DNS configuration and SSL certificate setup for Azure deployments. - [Microsoft Azure](/docs/infrastructure/providers/azure/index.md): tsdevstack on Azure uses Container Apps for backend services, App Service for Kong and Next.js, PostgreSQL Flexible Server for databases, and Azure Managed Redis. Azure Front Door provides a unified edge service combining CDN, WAF, SSL, and load balancing in one. Azure has the simplest architecture overall (~25-30 Terraform resources vs AWS's ~45). Front Door replaces three separate AWS services (CloudFront + ALB + ACM) with one unified service. There are two security tiers: Standard and Premium (adding Private Link origins and managed WAF rulesets). - [GCP Account Setup](/docs/infrastructure/providers/gcp/account-setup.md): Setting up GCP for tsdevstack deployments. Each environment uses a separate GCP project — repeat these steps for each project. - [GCP Architecture](/docs/infrastructure/providers/gcp/architecture.md): What gets deployed when you run infra:deploy on GCP and how traffic flows through the system. - [GCP CI/CD](/docs/infrastructure/providers/gcp/cicd.md): Set up Workload Identity Federation (WIF) for GitHub Actions to authenticate with GCP without storing service account keys. For generating workflow files and general CI/CD setup, see CI/CD Setup. - [GCP Cost Estimation](/docs/infrastructure/providers/gcp/cost-estimation.md): These are estimates based on published GCP pricing as of July 2026 in a US region (us-central1). Actual costs depend on your region, traffic, and any pricing changes by Google. Always verify with the official pricing pages linked at the bottom. - [GCP DNS & Domains](/docs/infrastructure/providers/gcp/dns-and-domains.md): Provider-specific DNS configuration and SSL certificate setup for GCP deployments. - [Google Cloud Platform (GCP)](/docs/infrastructure/providers/gcp/index.md): tsdevstack on GCP uses Cloud Run for all compute (backends, Kong gateway, Next.js frontends, and workers), with Cloud SQL for PostgreSQL, Memorystore for Redis, and a Global HTTPS Load Balancer with Cloud Armor WAF at the edge. Cloud Run scales to zero natively, with 2-8 second cold starts, so minInstances: 0 is a real option for development environments. (Azure supports it too; AWS does not.) The architecture uses ~35 Terraform resources. - [Service Configuration](/docs/infrastructure/service-configuration.md): Customize how your services run in the cloud using infrastructure.json. - [Resend (Email Notifications)](/docs/integrations/resend.md): Resend is the default email provider for production deployments. The framework uses it for transactional emails — verification, password resets, invitations, etc. In local development, emails are logged to the console. No Resend account is needed until you deploy to the cloud. - [Architecture Overview](/docs/introduction/architecture-overview.md): tsdevstack uses a gateway-first architecture where all traffic flows through a central API gateway before reaching your services. This pattern provides consistent security, routing, and observability across all your APIs. - [Supported Apps](/docs/introduction/supported-apps.md): tsdevstack supports multiple application types within a single monorepo. - [Adding Apps](/docs/local-development/adding-apps.md): Use npx tsdevstack add-service to add new applications to your monorepo. - [Database Migrations](/docs/local-development/database-migrations.md): Every NestJS service with a database owns its schema at apps//prisma/schema.prisma and gets its own Postgres database. Migrations are standard Prisma; the framework wires up the connection and runs them for you at the right times, locally and in the cloud. - [Debugging](/docs/local-development/debugging.md): Tips for debugging issues in local development. - [Running Locally](/docs/local-development/running-locally.md): tsdevstack provides a complete local development environment with Docker Compose. - [Tech Stack](/docs/local-development/tech-stack.md): tsdevstack is built on battle-tested technologies chosen for reliability, developer experience, and production readiness. - [cli-mcp](/docs/packages/cli-mcp.md): @tsdevstack/cli-mcp is the Model Context Protocol server plugin for the tsdevstack CLI. It exposes 54 tools and 12 resources so AI agents like Claude Code, Cursor, and VS Code Copilot can understand and assist with your project — deployments, debugging, querying state, and following framework patterns. Installed automatically by @tsdevstack/cli init — no separate setup needed. - [nest-common](/docs/packages/nest-common.md): @tsdevstack/nest-common is the shared NestJS library for tsdevstack projects. It provides authentication, secrets management, Redis, observability, rate limiting, notifications, background jobs, service-to-service communication, and database utilities — all configured to work across GCP, AWS, and Azure. Pre-installed in all NestJS service templates — no separate setup needed. - [react-bot-detection](/docs/packages/react-bot-detection.md): @tsdevstack/react-bot-detection is a React library for client-side bot detection using behavioral analysis and honeypot fields. Zero dependencies beyond React, SSR-safe, fully typed. - [tsdevstack (CLI)](/docs/packages/tsdevstack.md): tsdevstack is the command-line interface for the framework. It handles project scaffolding, local development config generation, cloud secret management, infrastructure deployment, database migrations, scheduled jobs, and CI/CD — across GCP, AWS, and Azure. Shorthand alias: npx tsds works anywhere npx tsdevstack does. - [CLI Commands](/docs/reference/cli-commands.md): The tsdevstack CLI handles project management, code generation, and deployment workflows. - [Glossary](/docs/reference/glossary.md): Key terms used throughout the tsdevstack documentation. - [nest-common 0.3.0](/docs/releases/nest-common-0.3.0.md): Released: June 11, 2026 This release ships @tsdevstack/nest-common 0.3.0 only. CLI packages are unchanged. - [v0.1.1 – v0.1.4](/docs/releases/v0.1.1-0.1.4.md): Released: February 22 – 23, 2026 Initial publish workflow stabilisation. Four patch releases over a single day shaking out the GitHub Actions publish pipeline and getting the first packages live on npm. GitHub Actions publish workflow iterations (auth, registry tagging, lockfile sync after publish)publishConfig.access: public set on the unscoped tsdevstack packageOne flaky runCommand test skipped in CI No user-facing functional changes — these versions exist purely because each fix needed a published artefact to verify the next workflow step. - [v0.1.17 – v0.1.18](/docs/releases/v0.1.17-0.1.18.md): Released: February 26 – 27, 2026 CI/CLI decoupling block. Generated CI workflows are no longer tied to the cli plan that produced them — workflows can run in CI without the cli having to re-plan first.Build scope and package build-order fixes so the workspace builds reliably from a clean checkout.Templates updated for the new CI/CLI contract.init no longer runs the cloud-init step automatically — cloud:init is a deliberate, separate command users invoke when they're ready to deploy. - [v0.1.19 – v0.1.23](/docs/releases/v0.1.19-0.1.23.md): Released: February 28 – March 1, 2026 Load balancer + frontend deployment hardening. Load balancer deployment fixes (terraform bucket handling, deploy ordering)Frontend deployment fixes (build pipeline, asset upload)infra:generate-ci and infra:deploy-services CI generation fixesCI Node version upgrade + cli lib relinkingCli package version handling fixFull-stack template wiring (full-stack, "IaF" milestones)Resend integration docs - [v0.1.24 – v0.1.27](/docs/releases/v0.1.24-0.1.27.md): Released: March 1 – 5, 2026 Cloud SDK migration + Azure provider integration. - [v0.1.28](/docs/releases/v0.1.28.md): Released: March 8, 2026 Kong restructure + AWS bootstrap fixes. Kong configuration restructured: kong-related files split into dedicated config files instead of being bundled into the main compose; eliminates unnecessary kong env-var injection into backend services.AWS bootstrap fix: infra:bootstrap ordering and resource creation fixes.Redirect domains removed from default infrastructure (were causing avoidable DNS records).Infra constants refactoring: shared constants pulled into a single module instead of duplicated across providers.Azure ACR pull fix refactored into a cleaner shared utility.AWS setup docs updated. - [v0.1.29 – v0.1.30](/docs/releases/v0.1.29-0.1.30.md): Released: March 9, 2026 Final patch pair before v0.2.0. AWS Kong URL fix — the backend service URL Kong used for upstreams was constructed incorrectly in some AWS deployments.Detached worker CI fix — infra:remove-detached-worker workflow generation fix.General CI workflow fixes. - [v0.1.5](/docs/releases/v0.1.5.md): Released: February 24, 2026 First beta-quality release of the cli-core package. cli-core package internals renamed and reorganised for the public surfaceFinal touches before opening up to external testersinit gains conditional sync (only runs when there are services to sync against)Docs site content sweep - [v0.1.6 – v0.1.16](/docs/releases/v0.1.6-0.1.16.md): Released: February 24 – 25, 2026 Alpha stabilisation block — eleven small releases over two days, each landing one or two fixes as the cli was exercised end-to-end against real templates. Highlights from the window: init and publish flow fixes (0.1.6)Core / monorepo wiring fixes (0.1.7 – 0.1.9)Template + nest-common dependency fixes (0.1.10)Next.js auth template + secrets fixes (0.1.11)Initial DB migration support during init (0.1.12)MCP server polish + favicon (0.1.13)Docs and package metadata sweep (0.1.14 – 0.1.16) Many releases in this band shipped 1 – 3 commits each. Use git log v0.1.5..v0.1.16 for the full per-version breakdown. - [v0.10.0](/docs/releases/v0.10.0.md): Released: October 24, 2026 Node.js 24 and NestJS 12 are the headline: new projects start on Node 24, with node:24-slim images and Node 24 CI workflows, and every NestJS package is on 12. The rest of the stack moves with it: Next.js 16.4, React 19.3, Prisma 7.10, ioredis 6, BullMQ 6, OpenTelemetry 3, the current Google and Azure SDKs, and the toolchain (lerna 10, Rslib 1.0, Rstest 0.12, Vitest 5). Existing projects need the upgrade steps below. - [v0.2.0](/docs/releases/v0.2.0.md): Released: April 4, 2026 - [v0.2.1](/docs/releases/v0.2.1.md): Released: April 4, 2026 Polish release shortly after v0.2.0. cli-mcp: cleanup of resource handlers and tool registration; read-project-file resource added; minor query/tool refactors.Docs: mcp-server, cli-mcp, glossary, and several READMEs (cli-core, cli-mcp, nest-common) updated. - [v0.2.2](/docs/releases/v0.2.2.md): Released: April 6, 2026 cli-core README rewritten end-to-end (~150 line additions) with current command surface and architecture overview.v0.2.0 release notes expanded with additional context. - [v0.2.3](/docs/releases/v0.2.3.md): Released: April 7, 2026 npx tsdevstack init now runs git init automatically as part of the scaffold, so the new project starts as a clean git repo without a manual step.Template .gitignore synced with the framework's own (secrets patterns, observability data dirs, etc.). - [v0.2.4](/docs/releases/v0.2.4.md): Released: April 7, 2026 Init-flow + GCP-bootstrap fixes that landed same day as v0.2.3. init git-repo handling: git init moved out of clone-template-repo (which was producing a nested .git dir inside the cloned template) and runs in the project root after the clone instead.Lockfile reconciliation: init now runs npm install a second time after the first install to work around an upstream npm bug where the first install can leave the lockfile out of sync with workspace dependencies.GCP infra:bootstrap: 15-second delay inserted between API enablement and IAM binding to avoid a propagation race that intermittently caused IAM operations to fail with "API not yet enabled."infra:deploy: now prints a DNS verification table at the end summarising what to point at where.Template .gitignore synced (secrets patterns, npmrc, removed outdated Vercel section). - [v0.2.5](/docs/releases/v0.2.5.md): Released: April 8, 2026 Docs-site landing page rework. New homepage hero, feature grid, and floating video components.New ConfigSnippet component for inline live configuration examples.SocialLinks component for the footer.README link cleanups across packages. No CLI / runtime changes. - [v0.2.6](/docs/releases/v0.2.6.md): Released: April 14, 2026 CLI hints rewritten: init, generate-docker-compose, and generate-kong next-steps no longer recommend raw docker compose commands. They now point users at npx tsdevstack sync (which is the supported orchestration path), and cloud:init is shown as the last step since it isn't needed for local development.OWASP compliance docs: auth template and infrastructure already followed OWASP guidelines; this release documents that. Adds OWASP Top 10 coverage table, cheat-sheet alignment notes, and references throughout the user-facing docs and READMEs. - [v0.2.7](/docs/releases/v0.2.7.md): Released: April 21, 2026 - [v0.2.8](/docs/releases/v0.2.8.md): Released: April 25, 2026 - [v0.3.0](/docs/releases/v0.3.0.md): Released: May 3, 2026 - [v0.3.1](/docs/releases/v0.3.1.md): Released: May 9, 2026 - [v0.3.2](/docs/releases/v0.3.2.md): Released: June 1, 2026 - [v0.5.0](/docs/releases/v0.5.0.md): Released: July 24, 2026 - [v0.6.0](/docs/releases/v0.6.0.md): Released: July 26, 2026 This release brings the framework's dependencies up to date: the CLI, @tsdevstack/nest-common, and all templates move to current package versions across the board. A few changes need action on your side; those come first. - [v0.6.1](/docs/releases/v0.6.1.md): Released: August 8, 2026 Redis improvements across rate limiting, messaging, and the Redis instances the framework provisions. No API changes. - [v0.7.0](/docs/releases/v0.7.0.md): Released: August 8, 2026 This release is about AI coding agents: a set of installable agent skills that teach your assistant how tsdevstack works, an init that sets them up for you, and a scaffold that tells any agent where to find what it needs. - [v0.8.0](/docs/releases/v0.8.0.md): Released: October 2, 2026 This release is about the gateway. API keys are now real runtime data: you create, limit, rotate and revoke them through the auth-service, and the gateway enforces them on every request with no redeploy. Along the way we layered the trust between the gateway and your services, gave users roles, and made the gateway image the same everywhere. It has breaking changes; the upgrade guide at the end walks through them in order. - [v0.9.0](/docs/releases/v0.9.0.md): Released: October 24, 2026 Three things stand out: RustFS replaces MinIO as the local S3 server (MinIO's images were removed from Docker Hub), rate limiting uses provider-specific client address headers and per-route limits, and Kong and Next.js scale on Azure App Service. Also in this release: IPv6 on every provider, deploys that wait out capacity shortages, database readiness at startup, cleaner logs. - [Cloud Secrets](/docs/secrets/cloud-secrets.md): In production, tsdevstack integrates with cloud secret managers instead of using local files. Your code uses the same SecretsService interface, but secrets are fetched from your cloud provider. - [How Secrets Work](/docs/secrets/how-secrets-work.md): tsdevstack uses a structured secrets system that eliminates manual .env file management. Instead of scattering environment variables across multiple files, secrets are centrally defined and automatically distributed to each service. - [Local Secrets](/docs/secrets/local-secrets.md): During local development, tsdevstack stores secrets in JSON files and provides them to services through a consistent interface. This page covers how to work with secrets in your local environment. - [User vs Framework Secrets](/docs/secrets/user-vs-framework.md): tsdevstack manages two categories of secrets: those the framework generates automatically, and those you provide. Understanding the difference helps you know what to configure and what to leave alone. - [Compliance Readiness](/docs/security/compliance-readiness.md): tsdevstack implements a security-first architecture across all three cloud providers. The framework enforces encryption, network isolation, zero-credential runtimes, and environment separation as non-optional defaults — not configurable afterthoughts. This page maps the framework's built-in security controls against major compliance frameworks to help teams understand what's covered out of the box and what remains their responsibility. Bottom line: tsdevstack provides all the technical infrastructure controls required by SOC 2, GDPR, and ISO 27001. Every technical requirement — encryption, network isolation, access control, audit logging, secrets management — is handled by the framework across all three providers. What remains is purely organizational: writing policies, conducting audits, and establishing review processes. The infrastructure is ready; the paperwork is yours.