Azure Static Web Apps seamlessly integrates globally distributed hosting for your static content, serverless APIs powered by Azure Functions, as well as features like authentication, custom routing, and route-based authorization.
With the new Static Web Apps CLI, you can now run your entire full-stack web app locally in your development environment and access many of the platform’s capabilities without deploying your app. The CLI hosts your frontend and API on a single localhost endpoint and emulates authentication, custom routing, and authorization rules.
Static Web Apps CLI can serve static content from a folder. It also works great with local development servers from any frontend framework, including React, Angular, Next.js, and Blazor WebAssembly.
Getting started
Install the Static Web Apps CLI from npm:
npm install -g @azure/static-web-apps-cli
To serve static content from a folder, run:
swa start ./my-app
Your app is accessible at http://localhost:4280. If you have any custom route logic or settings configured in a staticwebapp.config.json file, it’ll apply them automatically.
Run and test your full-stack app
Use a framework dev server
Most frontend frameworks provide a local dev server that allows you to iterate on your app quickly using features such as hot module reloading. Static Web Apps CLI can proxy traffic to a dev server that’s already running.
How you start your app’s dev server depends on your framework. Here are some examples:
# Create React App
npm start
# Next.js
npm run dev
# Blazor WebAssembly
dotnet watch run
Then, in a separate terminal, start the CLI and provide your framework dev server’s local address:
swa start http://localhost:3000
Requests to http://localhost:4280 are proxied to your dev server. Using that endpoint, you can test out how your app interacts with Static Web Apps features like authentication and API functions.
Simulate authentication
Azure Static Web Apps provides integrated authentication using providers such as GitHub, Twitter, and Azure Active Directory. The Static Web Apps CLI simulates the same authentication flow so you can test your authentication/authorization logic locally.
When your app requests a Static Web Apps authentication login URI, such as /.auth/login/github, the CLI displays a page that allows you to log in as any identity by specifying their information. This works with all supported identity providers without any additional configuration.
You can use this to easily test your app using different identities and roles. The /.auth/me endpoint returns information about the current user, and API function calls include a claims principal header—they work just like they do when your app is deployed to Azure! Learn more about how to access user information from our documentation.
Run API functions
If your app has an Azure Functions API, you can include its location when you start the Static Web Apps CLI:
swa start http://localhost:5000 --api ./api
Behind the scenes, as the CLI launches, it also starts the API app using the Azure Functions Core Tools. You can access your API functions at http://localhost:4280/api/*. Because the frontend app and serverless functions are served from the same origin, you don’t have to worry about CORS (cross-origin resource sharing) when you call your APIs.
What’s next?
Static Web Apps CLI is currently in preview. We're only getting started and have lots more planned!
Together with the Azure Static Web Apps VS Code extension, the CLI will play an important role in our local development experience. We plan on offering an integrated debugging experience in VS Code that lets you start your entire stack and attach debuggers to both your frontend and backend apps.
While we are initially focusing on running apps locally, we plan on expanding the CLI with more commands such as creating Static Web Apps projects.
Try it today
Read the Azure Static Web Apps local development documentation to learn more and get started.
If you have feedback or would like to contribute, check out the Azure Static Web Apps CLI on GitHub.