Annoncé le 7 octobre 2026, LocalStack for Azure est un émulateur local destiné au développement et aux tests de services Azure. Il accepte plusieurs outils d’infrastructure courants, mais certains réglages de sécurité sont enregistrés sans être appliqués : un test local portant sur ces protections ne valide donc pas leur comportement dans Azure. (annonce de LocalStack, documentation App Service)
Des outils familiers, sans garantie de parité avec Azure
LocalStack répertorie les modèles ARM et Bicep, les modules Terraform, les programmes Pulumi, Azure CLI et Azure Developer CLI. L’aperçu couvre aussi des services comme AKS, Azure Functions, App Service, Cosmos DB, Azure SQL Database, Storage et Service Bus. La page produit indique qu’un compte Azure n’est pas nécessaire pour le développement et les tests en local. (présentation de LocalStack for Azure)
Cette compatibilité permet de travailler avec des outils et des services Azure dans un environnement local. Elle ne signifie pas que chaque opération ou comportement est reproduit : LocalStack présente le produit comme un outil de développement et de test, et non comme un remplacement d’Azure en production.
Les réglages de sécurité d’App Service ne sont pas tous appliqués
La documentation de LocalStack indique que les restrictions d’accès, les paramètres d’authentification, les politiques relatives aux identifiants de publication et l’option httpsOnly sont enregistrés, mais non appliqués. L’application est servie en HTTP. La présence d’un réglage dans la configuration ne suffit donc pas à valider la protection correspondante. (documentation App Service)
Virtual Network a une limite distincte : l’émulateur stocke et renvoie les métadonnées des ressources, mais ne route pas le trafic réseau et n’applique pas les règles de sécurité. Il ne permet donc pas de vérifier localement le fonctionnement de ces règles ou du routage. (documentation Virtual Network)
Storage vérifie certains accès, mais pas tous de la même façon
Les contrôles de Storage ne sont pas absents dans leur ensemble. LocalStack décrit la vérification des signatures Shared Key et des signatures SAS, ou signatures d’accès partagé. Pour SAS, les contrôles documentés portent notamment sur la période de validité, l’adresse IP, le protocole et les permissions. (documentation Storage Account)
Le comportement des jetons bearer est différent : leur présence suffit, sauf si l’application du contrôle d’accès en fonction du rôle (RBAC) est activée. Pour une SAS de délégation utilisateur, l’autorisation RBAC du principal à l’origine de la requête n’est pas vérifiée à nouveau. Un test local de ces chemins d’autorisation ne garantit donc pas que les mêmes contrôles s’appliqueront dans Azure.
Oryx sur Apple Silicon et workflows de déploiement
La limite d’architecture concerne les déploiements de code App Service qui utilisent Oryx. Ses images de build et d’exécution sont en amd64. Pour Apple Silicon, LocalStack décrit une configuration avec Rosetta et le framework Apple Virtualization pour l’émulation amd64 ; un build sous QEMU peut planter. Les images de conteneur personnalisées dotées d’une variante ARM64 ne sont pas concernées par cette limite propre à Oryx. (documentation App Service)
La documentation décrit aussi un workflow de base avec des slots de staging : déployer sur un slot distinct, le servir sur son propre nom d’hôte, puis l’échanger avec le slot de production. Le routage du trafic, l’échange avec prévisualisation et l’échange automatique ne sont pas implémentés. L’état App Service est conservé en mémoire et disparaît à l’arrêt de l’émulateur.
Un aperçu gratuit, avec une disponibilité générale prévue début 2027
LocalStack a annoncé un accès à l’aperçu public gratuit et en libre-service. L’entreprise prévoit la disponibilité générale début 2027 et indique que ses tarifs seront annoncés à cette étape. (annonce de LocalStack, page produit)
