Work with Azure Functions Core Tools

Azure Functions Core Tools lets you develop and test your functions on your local computer from the command prompt or terminal. Your local functions can connect to live Azure services, and you can debug your functions on your local computer using the full Functions runtime. You can even deploy a function app to your Azure subscription.


Do not mix local development with portal development in the same function app. When you create and publish functions from a local project, you should not try to maintain or modify project code in the portal.

Developing functions on your local computer and publishing them to Azure using Core Tools follows these basic steps:

Core Tools versions

There are three versions of Azure Functions Core Tools.* The version you use depends on your local development environment, choice of language, and level of support required:

You can only install one version of Core Tools on a given computer. Unless otherwise noted, the examples in this article are for version 3.x.

* An experimental version of Azure Functions is available that lets you run C# functions on the .NET 6.0 preview. To learn more, see the Azure Functions v4 early preview page.


Azure Functions Core Tools currently depends on either the Azure CLI or Azure PowerShell for authenticating with your Azure account. This means that you must install one of these tools to be able to publish to Azure from Azure Functions Core Tools.

Install the Azure Functions Core Tools

Azure Functions Core Tools includes a version of the same runtime that powers Azure Functions runtime that you can run on your local development computer. It also provides commands to create functions, connect to Azure, and deploy function projects.

Version 3.x and 2.x

Version 3.x/2.x of the tools uses the Azure Functions runtime that is built on .NET Core. This version is supported on all platforms .NET Core supports, including Windows, macOS, and Linux.


You can bypass the requirement for installing the .NET Core SDK by using extension bundles.

The following steps use a Windows installer (MSI) to install Core Tools v3.x. For more information about other package-based installers, which are required to install Core Tools v2.x, see the Core Tools readme.

  1. Download and run the Core Tools installer, based on your version of Windows:

  2. If you don't plan to use extension bundles, install the .NET Core 3.x SDK for Windows.

Create a local Functions project

A Functions project directory contains the files host.json and local.settings.json, along with subfolders that contain the code for individual functions. This directory is the equivalent of a function app in Azure. To learn more about the Functions folder structure, see the Azure Functions developers guide.

Version 3.x/2.x requires you to select a default language for your project when it is initialized. In version 3.x/2.x, all functions added use default language templates. In version 1.x, you specify the language each time you create a function.

In the terminal window or from a command prompt, run the following command to create the project and local Git repository:

func init MyFunctionProj


Java uses a Maven archetype to create the local Functions project, along with your first HTTP triggered function. Use the following command to create your Java project: mvn archetype:generate -DarchetypeArtifactId=azure-functions-archetype. For an example using the Maven archetype, see the Command line quickstart.

When you provide a project name, a new folder with that name is created and initialized. Otherwise, the current folder is initialized.
In version 3.x/2.x, when you run the command you must choose a runtime for your project.

Select a worker runtime:

Use the up/down arrow keys to choose a language, then press Enter. If you plan to develop JavaScript or TypeScript functions, choose node, and then select the language. TypeScript has some additional requirements.

The output looks like the following example for a JavaScript project:

Select a worker runtime: node
Writing .gitignore
Writing host.json
Writing local.settings.json
Writing C:\myfunctions\myMyFunctionProj\.vscode\extensions.json
Initialized empty Git repository in C:/myfunctions/myMyFunctionProj/.git/

func init supports the following options, which are version 3.x/2.x-only, unless otherwise noted:

Option Description
--csx Creates .NET functions as C# script, which is the version 1.x behavior. Valid only with --worker-runtime dotnet.
--docker Creates a Dockerfile for a container using a base image that is based on the chosen --worker-runtime. Use this option when you plan to publish to a custom Linux container.
--docker-only Adds a Dockerfile to an existing project. Prompts for the worker-runtime if not specified or set in local.settings.json. Use this option when you plan to publish an existing project to a custom Linux container.
--force Initialize the project even when there are existing files in the project. This setting overwrites existing files with the same name. Other files in the project folder aren't affected.
--language Initializes a language specific project. Currently supported when --worker-runtime set to node. Options are typescript and javascript. You can also use --worker-runtime javascript or --worker-runtime typescript.
--managed-dependencies Installs managed dependencies. Currently, only the PowerShell worker runtime supports this functionality.
--source-control Controls whether a git repository is created. By default, a repository isn't created. When true, a repository is created.
--worker-runtime Sets the language runtime for the project. Supported values are: csharp, dotnet, javascript,node (JavaScript), powershell, python, and typescript. For Java, use Maven.When not set, you're prompted to choose your runtime during initialization.


By default, version 2.x and later versions of the Core Tools create function app projects for the .NET runtime as C# class projects (.csproj). These C# projects, which can be used with Visual Studio or Visual Studio Code, are compiled during testing and when publishing to Azure. If you instead want to create and work with the same C# script (.csx) files created in version 1.x and in the portal, you must include the --csx parameter when you create and deploy functions.

Register extensions

With the exception of HTTP and timer triggers, Functions bindings in runtime version 2.x and higher are implemented as extension packages. HTTP bindings and timer triggers don't require extensions.

To reduce incompatibilities between the various extension packages, Functions lets you reference an extension bundle in your host.json project file. If you choose not to use extension bundles, you also need to install .NET Core 2.x SDK locally and maintain an extensions.csproj with your functions project.

In version 2.x and beyond of the Azure Functions runtime, you have to explicitly register the extensions for the binding types used in your functions. You can choose to install binding extensions individually, or you can add an extension bundle reference to the host.json project file. Extension bundles removes the chance of having package compatibility issues when using multiple binding types. It is the recommended approach for registering binding extensions. Extension bundles also removes the requirement of installing the .NET Core 2.x SDK.

Use extension bundles

The easiest way to install binding extensions is to enable extension bundles. When you enable bundles, a predefined set of extension packages is automatically installed.

To enable extension bundles, open the host.json file and update its contents to match the following code:

    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[1.*, 2.0.0)"

To learn more, see Register Azure Functions binding extensions. You should add extension bundles to the host.json before you add bindings to the function.json file.

Explicitly install extensions

If you aren't able to use extension bundles, you can use Azure Functions Core Tools locally to install the specific extension packages required by your project.


You can't explicitly install extensions in a function app that is using extension bundles. Remove the extensionBundle section in host.json before explicitly installing extensions.

The following items describe some reasons you might need to install extensions manually:

  • You need to access a specific version of an extension not available in a bundle.
  • You need to access a custom extension not available in a bundle.
  • You need to access a specific combination of extensions not available in a single bundle.


To manually install extensions by using Core Tools, you must have the .NET Core 2.x SDK installed. The .NET Core SDK is used by Azure Functions Core Tools to install extensions from NuGet. You don't need to know .NET to use Azure Functions extensions.

When you explicitly install extensions, a .NET project file named extensions.csproj is added to the root of your project. This file defines the set of NuGet packages required by your functions. While you can work with the NuGet package references in this file, Core Tools lets you install extensions without having to manually edit the file.

There are several ways to use Core Tools to install the required extensions in your local project.

Install all extensions

Use the following command to automatically add all extension packages used by the bindings in your local project:

func extensions install

The command reads the function.json file to see which packages you need, installs them, and rebuilds the extensions project (extensions.csproj). It adds any new bindings at the current version but does not update existing bindings. Use the --force option to update existing bindings to the latest version when installing new ones.

If your function app uses bindings that Core Tools does not recognize, you must manually install the specific extension.

Install a specific extension

Use the following command to install a specific extension package at a specific version, in this case the Storage extension:

func extensions install --package Microsoft.Azure.WebJobs.Extensions.Storage --version 4.0.2

Local settings file

The local.settings.json file stores app settings, connection strings, and settings used by local development tools. Settings in the local.settings.json file are used only when you're running projects locally. The local settings file has this structure:

  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "<language worker>",
    "AzureWebJobsStorage": "<connection-string>",
    "AzureWebJobsDashboard": "<connection-string>",
    "MyBindingConnection": "<binding-connection-string>",
    "AzureWebJobs.HttpExample.Disabled": "true"
  "Host": {
    "LocalHttpPort": 7071,
    "CORS": "*",
    "CORSCredentials": false
  "ConnectionStrings": {
    "SQLConnectionString": "<sqlclient-connection-string>"

These settings are supported when you run projects locally:

Setting Description
IsEncrypted When this setting is set to true, all values are encrypted with a local machine key. Used with func settings commands. Default value is false. You might want to encrypt the local.settings.json file on your local computer when it contains secrets, such as service connection strings. The host automatically decrypts settings when it runs. Use the func settings decrypt command before trying to read locally encrypted settings.
Values Array of application settings and connection strings used when a project is running locally. These key-value (string-string) pairs correspond to application settings in your function app in Azure, like AzureWebJobsStorage. Many triggers and bindings have a property that refers to a connection string app setting, like Connection for the Blob storage trigger. For these properties, you need an application setting defined in the Values array. See the subsequent table for a list of commonly used settings.
Values must be strings and not JSON objects or arrays. Setting names can't include a colon (:) or a double underline (__). Double underline characters are reserved by the runtime, and the colon is reserved to support dependency injection.
Host Settings in this section customize the Functions host process when you run projects locally. These settings are separate from the host.json settings, which also apply when you run projects in Azure.
LocalHttpPort Sets the default port used when running the local Functions host (func host start and func run). The --port command-line option takes precedence over this setting. For example, when running in Visual Studio IDE, you may change the port number by navigating to the "Project Properties -> Debug" window and explicitly specifying the port number in a host start --port <your-port-number> command that can be supplied in the "Application Arguments" field.
CORS Defines the origins allowed for cross-origin resource sharing (CORS). Origins are supplied as a comma-separated list with no spaces. The wildcard value (*) is supported, which allows requests from any origin.
CORSCredentials When set to true, allows withCredentials requests.
ConnectionStrings A collection. Don't use this collection for the connection strings used by your function bindings. This collection is used only by frameworks that typically get connection strings from the ConnectionStrings section of a configuration file, like Entity Framework. Connection strings in this object are added to the environment with the provider type of System.Data.SqlClient. Items in this collection aren't published to Azure with other app settings. You must explicitly add these values to the Connection strings collection of your function app settings. If you're creating a SqlConnection in your function code, you should store the connection string value with your other connections in Application Settings in the portal.

The following application settings can be included in the Values array when running locally:

Setting Values Description
AzureWebJobsStorage Storage account connection string, or
Contains the connection string for an Azure storage account. Required when using triggers other than HTTP. For more information, see the AzureWebJobsStorage reference.
When you have the Azure Storage Emulator installed locally and you set AzureWebJobsStorage to UseDevelopmentStorage=true, Core Tools uses the emulator. The emulator is useful during development, but you should test with an actual storage connection before deployment.
AzureWebJobs.<FUNCTION_NAME>.Disabled true|false To disable a function when running locally, add "AzureWebJobs.<FUNCTION_NAME>.Disabled": "true" to the collection, where <FUNCTION_NAME> is the name of the function. To learn more, see How to disable functions in Azure Functions
Indicates the targeted language of the Functions runtime. Required for version 2.x and higher of the Functions runtime. This setting is generated for your project by Core Tools. To learn more, see the FUNCTIONS_WORKER_RUNTIME reference.
FUNCTIONS_WORKER_RUNTIME_VERSION ~7 Indicates that PowerShell 7 be used when running locally. If not set, then PowerShell Core 6 is used. This setting is only used when running locally. When running in Azure, the PowerShell runtime version is determined by the powerShellVersion site configuration setting, which can be set in the portal.

By default, these settings are not migrated automatically when the project is published to Azure. Use the --publish-local-settings switch when you publish to make sure these settings are added to the function app in Azure. Note that values in ConnectionStrings are never published.

The function app settings values can also be read in your code as environment variables. For more information, see the Environment variables section of these language-specific reference topics:

When no valid storage connection string is set for AzureWebJobsStorage and the emulator isn't being used, the following error message is shown:

Missing value for AzureWebJobsStorage in local.settings.json. This is required for all triggers other than HTTP. You can run 'func azure functionapp fetch-app-settings <functionAppName>' or specify a connection string in local.settings.json.

Get your storage connection strings

Even when using the Microsoft Azure Storage Emulator for development, you may want to test with an actual storage connection. Assuming you have already created a storage account, you can get a valid storage connection string in one of the following ways:

  • From the Azure portal, search for and select Storage accounts. Select Storage accounts from Azure portal

    Select your storage account, select Access keys in Settings, then copy one of the Connection string values. Copy connection string from Azure portal

  • Use Azure Storage Explorer to connect to your Azure account. In the Explorer, expand your subscription, expand Storage Accounts, select your storage account, and copy the primary or secondary connection string.

    Copy connection string from Storage Explorer

  • Use Core Tools from the project root to download the connection string from Azure with one of the following commands:

    • Download all settings from an existing function app:

      func azure functionapp fetch-app-settings <FunctionAppName>
    • Get the Connection string for a specific storage account:

      func azure storage fetch-connection-string <StorageAccountName>

      When you aren't already signed in to Azure, you're prompted to do so. These commands overwrite any existing settings in the local.settings.json file.

Create a function

To create a function, run the following command:

func new

In version 3.x/2.x, when you run func new you are prompted to choose a template in the default language of your function app, then you are also prompted to choose a name for your function. In version 1.x, you are also prompted to choose the language.

Select a language: Select a template:
Blob trigger
Cosmos DB trigger
Event Grid trigger
HTTP trigger
Queue trigger
Service Bus Queue trigger
Service Bus Topic trigger
Timer trigger

Function code is generated in a subfolder with the provided function name, as you can see in the following queue trigger output:

Select a language: Select a template: Queue trigger
Function name: [QueueTriggerJS] MyQueueTrigger
Writing C:\myfunctions\myMyFunctionProj\MyQueueTrigger\index.js
Writing C:\myfunctions\myMyFunctionProj\MyQueueTrigger\
Writing C:\myfunctions\myMyFunctionProj\MyQueueTrigger\sample.dat
Writing C:\myfunctions\myMyFunctionProj\MyQueueTrigger\function.json

You can also specify these options in the command using the following arguments:

Argument Description
--csx (Version 2.x and later versions.) Generates the same C# script (.csx) templates used in version 1.x and in the portal.
--language, -l The template programming language, such as C#, F#, or JavaScript. This option is required in version 1.x. In version 2.x and later versions, do not use this option or choose a language that matches the worker runtime.
--name, -n The function name.
--template, -t Use the func templates list command to see the complete list of available templates for each supported language.

For example, to create a JavaScript HTTP trigger in a single command, run:

func new --template "Http Trigger" --name MyHttpTrigger

To create a queue-triggered function in a single command, run:

func new --template "Queue Trigger" --name QueueTriggerJS

Run functions locally

To run a Functions project, run the Functions host. The host enables triggers for all functions in the project. The start command varies, depending on your project language.

func start


Version 1.x of the Functions runtime instead requires func host start.

func start supports the following options:

Option Description
--no-build Do no build current project before running. For dotnet projects only. Default is set to false. Not supported for version 1.x.
--cors-credentials Allow cross-origin authenticated requests (i.e. cookies and the Authentication header) Not supported for version 1.x.
--cors A comma-separated list of CORS origins, with no spaces.
--language-worker Arguments to configure the language worker. For example, you may enable debugging for language worker by providing debug port and other required arguments. Not supported for version 1.x.
--cert The path to a .pfx file that contains a private key. Only used with --useHttps. Not supported for version 1.x.
--password Either the password or a file that contains the password for a .pfx file. Only used with --cert. Not supported for version 1.x.
--port, -p The local port to listen on. Default value: 7071.
--pause-on-error Pause for additional input before exiting the process. Used only when launching Core Tools from an integrated development environment (IDE).
--script-root, --prefix Used to specify the path to the root of the function app that is to be run or deployed. This is used for compiled projects that generate project files into a subfolder. For example, when you build a C# class library project, the host.json, local.settings.json, and function.json files are generated in a root subfolder with a path like MyProject/bin/Debug/netstandard2.0. In this case, set the prefix as --script-root MyProject/bin/Debug/netstandard2.0. This is the root of the function app when running in Azure.
--timeout, -t The timeout for the Functions host to start, in seconds. Default: 20 seconds.
--useHttps Bind to https://localhost:{port} rather than to http://localhost:{port}. By default, this option creates a trusted certificate on your computer.

When the Functions host starts, it outputs the URL of HTTP-triggered functions:

Found the following functions:

Job host started
Http Function MyHttpTrigger: http://localhost:7071/api/MyHttpTrigger


When running locally, authorization isn't enforced for HTTP endpoints. This means that all local HTTP requests are handled as authLevel = "anonymous". For more information, see the HTTP binding article.

Passing test data to a function

To test your functions locally, you start the Functions host and call endpoints on the local server using HTTP requests. The endpoint you call depends on the type of function.


Examples in this topic use the cURL tool to send HTTP requests from the terminal or a command prompt. You can use a tool of your choice to send HTTP requests to the local server. The cURL tool is available by default on Linux-based systems and Windows 10 build 17063 and later. On older Windows, you must first download and install the cURL tool.

For more general information on testing functions, see Strategies for testing your code in Azure Functions.

HTTP and webhook triggered functions

You call the following endpoint to locally run HTTP and webhook triggered functions:


Make sure to use the same server name and port that the Functions host is listening on. You see this in the output generated when starting the Function host. You can call this URL using any HTTP method supported by the trigger.

The following cURL command triggers the MyHttpTrigger quickstart function from a GET request with the name parameter passed in the query string.

curl --get http://localhost:7071/api/MyHttpTrigger?name=Azure%20Rocks

The following example is the same function called from a POST request passing name in the request body:

curl --request POST http://localhost:7071/api/MyHttpTrigger --data '{"name":"Azure Rocks"}'

You can make GET requests from a browser passing data in the query string. For all other HTTP methods, you must use cURL, Fiddler, Postman, or a similar HTTP testing tool.

Non-HTTP triggered functions

For all kinds of functions other than HTTP triggers and webhooks and Event Grid triggers, you can test your functions locally by calling an administration endpoint. Calling this endpoint with an HTTP POST request on the local server triggers the function.

To test Event Grid triggered functions locally, see Local testing with viewer web app.

You can optionally pass test data to the execution in the body of the POST request. This functionality is similar to the Test tab in the Azure portal.

You call the following administrator endpoint to trigger non-HTTP functions:


To pass test data to the administrator endpoint of a function, you must supply the data in the body of a POST request message. The message body is required to have the following JSON format:

    "input": "<trigger_input>"

The <trigger_input> value contains data in a format expected by the function. The following cURL example is a POST to a QueueTriggerJS function. In this case, the input is a string that is equivalent to the message expected to be found in the queue.

curl --request POST -H "Content-Type:application/json" --data '{"input":"sample queue data"}' http://localhost:7071/admin/functions/QueueTrigger

Using the func run command (version 1.x only)


The func run command is only supported in version 1.x of the tools. For more information, see the topic How to target Azure Functions runtime versions.

In version 1.x, you can also invoke a function directly by using func run <FunctionName> and provide input data for the function. This command is similar to running a function using the Test tab in the Azure portal.

func run supports the following options:

Option Description
--content, -c Inline content.
--debug, -d Attach a debugger to the host process before running the function.
--timeout, -t Time to wait (in seconds) until the local Functions host is ready.
--file, -f The file name to use as content.
--no-interactive Does not prompt for input. Useful for automation scenarios.

For example, to call an HTTP-triggered function and pass content body, run the following command:

func run MyHttpTrigger -c '{\"name\": \"Azure\"}'

Publish to Azure

The Azure Functions Core Tools supports two types of deployment: deploying function project files directly to your function app via Zip Deploy and deploying a custom Docker container. You must have already created a function app in your Azure subscription, to which you'll deploy your code. Projects that require compilation should be built so that the binaries can be deployed.


You must have the Azure CLI or Azure PowerShell installed locally to be able to publish to Azure from Core Tools.

A project folder may contain language-specific files and directories that shouldn't be published. Excluded items are listed in a .funcignore file in the root project folder.

Deploy project files

To publish your local code to a function app in Azure, use the publish command:

func azure functionapp publish <FunctionAppName>


Java uses Maven to publish your local project to Azure. Use the following command to publish to Azure: mvn azure-functions:deploy. Azure resources are created during initial deployment.

This command publishes to an existing function app in Azure. You'll get an error if you try to publish to a <FunctionAppName> that doesn't exist in your subscription. To learn how to create a function app from the command prompt or terminal window using the Azure CLI or Azure PowerShell, see Create a Function App for serverless execution. By default, this command uses remote build and deploys your app to run from the deployment package. To disable this recommended deployment mode, use the --nozip option.


When you create a function app in the Azure portal, it uses version 3.x of the Function runtime by default. To make the function app use version 1.x of the runtime, follow the instructions in Run on version 1.x. You can't change the runtime version for a function app that has existing functions.

The following publish options apply for all versions:

Option Description
--publish-local-settings -i Publish settings in local.settings.json to Azure, prompting to overwrite if the setting already exists. If you are using the Microsoft Azure Storage Emulator, first change the app setting to an actual storage connection.
--overwrite-settings -y Suppress the prompt to overwrite app settings when --publish-local-settings -i is used.

The following publish options are supported only for version 2.x and later versions:

Option Description
--publish-settings-only, -o Only publish settings and skip the content. Default is prompt.
--list-ignored-files Displays a list of files that are ignored during publishing, which is based on the .funcignore file.
--list-included-files Displays a list of files that are published, which is based on the .funcignore file.
--nozip Turns the default Run-From-Package mode off.
--build-native-deps Skips generating .wheels folder when publishing Python function apps.
--build, -b Performs build action when deploying to a Linux function app. Accepts: remote and local.
--additional-packages List of packages to install when building native dependencies. For example: python3-dev libevent-dev.
--force Ignore pre-publishing verification in certain scenarios.
--csx Publish a C# script (.csx) project.
--no-build Project isn't built during publishing. For Python, pip install isn't performed.
--dotnet-cli-params When publishing compiled C# (.csproj) functions, the core tools calls 'dotnet build --output bin/publish'. Any parameters passed to this will be appended to the command line.

Deploy custom container

Azure Functions lets you deploy your function project in a custom Docker container. For more information, see Create a function on Linux using a custom image. Custom containers must have a Dockerfile. To create an app with a Dockerfile, use the --dockerfile option on func init.

func deploy

The following custom container deployment options are available:

Option Description
--registry The name of a Docker Registry the current user signed-in to.
--platform Hosting platform for the function app. Valid options are kubernetes
--name Function app name.
--max Optionally, sets the maximum number of function app instances to deploy to.
--min Optionally, sets the minimum number of function app instances to deploy to.
--config Sets an optional deployment configuration file.

Monitoring functions

The recommended way to monitor the execution of your functions is by integrating with Azure Application Insights. You can also stream execution logs to your local computer. To learn more, see Monitor Azure Functions.

Application Insights integration

Application Insights integration should be enabled when you create your function app in Azure. If for some reason your function app isn't connected to an Application Insights instance, it's easy to do this integration in the Azure portal. To learn more, see Enable Application Insights integration.

Enable streaming logs

You can view a stream of log files being generated by your functions in a command-line session on your local computer.

Built-in log streaming

Use the logstream option to start receiving streaming logs of a specific function app running in Azure, as in the following example:

func azure functionapp logstream <FunctionAppName>


Built-in log streaming isn't yet enabled in Core Tools for function apps running on Linux in a Consumption plan. For these hosting plans, you instead need to use Live Metrics Stream to view the logs in near-real time.

Live Metrics Stream

You can view the Live Metrics Stream for your function app in a new browser window by including the --browser option, as in the following example:

func azure functionapp logstream <FunctionAppName> --browser

This type of streaming logs requires that Application Insights integration be enabled for your function app.

Next steps

Learn how to develop, test, and publish Azure Functions by using Azure Functions Core Tools Microsoft learn module Azure Functions Core Tools is open source and hosted on GitHub.
To file a bug or feature request, open a GitHub issue.