LocalStack eröffnete am 7. Oktober 2026 die öffentliche Vorschau von LocalStack for Azure. Die Umgebung soll Azure-Anwendungen lokal entwickeln und testen helfen. Für Tests von Sicherheitsregeln und Netzwerkverhalten reicht ein erfolgreicher lokaler Durchlauf jedoch nicht: Bei einigen App-Service-Einstellungen speichert der Emulator die Konfiguration, setzt sie aber nicht durch. Auch Virtual Network leitet keinen Datenverkehr weiter und wendet keine Sicherheitsregeln an. LocalStack kündigte die Vorschau als kostenlos und im Selbstbedienungsmodell nutzbar an.
Welche Azure-Workflows die Vorschau abdeckt
LocalStack führt ARM- und Bicep-Vorlagen, Terraform-Module, Pulumi-Programme sowie Skripte für Azure CLI und Azure Developer CLI als unterstützte Arbeitsabläufe auf. Die Vorschau umfasst ausgewählte Dienste wie AKS, Container Apps, Functions, App Service, Cosmos DB, Storage, Service Bus, Key Vault und Virtual Network. Das erleichtert es, bestehende Infrastrukturdefinitionen lokal auszuprobieren, bedeutet aber nicht, dass alle Azure-Operationen oder ihr Verhalten nachgebildet sind. LocalStack positioniert das Produkt für Entwicklung und Tests, nicht als Ersatz für Azure im Produktivbetrieb. Die Produktseite von LocalStack nennt allgemeine Verfügbarkeit für Anfang 2027 als Prognose; den Preis will das Unternehmen zur GA bekannt geben.
Warum App-Service- und Netzwerktests Grenzen haben
Bei App Service speichert LocalStack Zugriffsbeschränkungen, Authentifizierungseinstellungen, Richtlinien für Veröffentlichungsanmeldedaten und die Einstellung httpsOnly, setzt sie laut App-Service-Referenz aber nicht durch. Anfragen werden zugelassen, und die App wird über HTTP ausgeliefert. Ein erfolgreicher lokaler Zugriff belegt deshalb nicht, dass eine Zugriffssperre oder HTTPS-Erzwingung greift.
Virtual Network speichert und liefert Ressourcendaten zurück, leitet aber keinen Netzwerkverkehr weiter und erzwingt keine Sicherheitsregeln. Ein lokaler Test kann damit die Konfiguration von Netzwerkressourcen prüfen, nicht aber, ob eine Regel den tatsächlichen Datenverkehr blockiert oder zulässt. LocalStacks Virtual-Network-Referenz führt außerdem Funktionen wie Peering, VPN-Gateways, ExpressRoute, Load Balancer und Application Gateway als nicht implementiert auf.
Storage prüft manches, aber nicht jede Autorisierung
Die Storage-Emulation bildet mehrere Prüfungen ab: Bei Shared Key werden Signaturen kontrolliert; SAS-Token werden unter anderem auf Signatur, Gültigkeitszeitraum, IP-Adresse, Protokoll, Dienst, Ressourcentyp und Berechtigungen geprüft. Bei Bearer-Tokens wird dagegen standardmäßig nur geprüft, ob ein Token vorhanden ist. Eine Rechteprüfung über RBAC greift für diesen Pfad nur, wenn RBAC-Erzwingung aktiviert ist. Bei nutzerdelegierten SAS-Tokens wird die RBAC-Berechtigung der anfragenden Person nicht erneut geprüft. LocalStacks Storage-Account-Referenz beschreibt somit konkrete Prüfungen, aber keine vollständige Gleichheit mit dem Verhalten von Azure.
App Service, Slots und Apple Silicon
LocalStack unterstützt laut App-Service-Referenz einen grundlegenden Ablauf mit Staging-Slots: Eine App lässt sich in einem separaten Slot bereitstellen und anschließend in den Produktionsslot tauschen. Traffic-Routing, „Swap with preview“ und automatischer Slot-Tausch sind nicht implementiert. Der App-Service-Zustand liegt im Arbeitsspeicher und geht verloren, wenn der Emulator stoppt; gespeicherte App-Einträge bringen Container und Code nicht zurück.
Die Architekturgrenze betrifft Oryx-basierte Codebereitstellungen. Oryx-Build- und Laufzeit-Images gibt es für amd64. Für Apple Silicon beschreibt LocalStack Rosetta zusammen mit Apples Virtualization-Framework zur amd64-Emulation; Builds unter QEMU können abstürzen. Eigene Container-Images mit einer ARM64-Variante fallen nicht unter diese Oryx-Einschränkung.
