Develop Azure Functions locally using Core Tools

Azure Functions Core Tools lets you develop and test your functions on your local computer. When you're ready, you can also use Core Tools to deploy your code project to Azure and work with application settings.

Install the Azure Functions Core Tools

The recommended way to install Core Tools depends on the operating system of your local development computer.

For help with version-related issues, see Core Tools versions.

Create your local project

In the terminal window or from a command prompt, run the following command to create a project in the MyProjFolder folder:

func init MyProjFolder --worker-runtime dotnet-isolated 

func init MyProjFolder --worker-runtime dotnet 

func init MyProjFolder --worker-runtime javascript --model V4

func init MyProjFolder --worker-runtime javascript --model V3

func init MyProjFolder --worker-runtime typescript --model V4

func init MyProjFolder --worker-runtime typescript --model V3

func init MyProjFolder --worker-runtime powershell

func init MyProjFolder --worker-runtime python --model V2

func init MyProjFolder --worker-runtime python

When you run func init without the --worker-runtime option, you're prompted to choose your project language. To learn more about the available options for the func init command, see the func init reference.

Create a function

To add a function to your project, run the func new command using the --template option to select your trigger template. The following example creates an HTTP trigger named MyHttpTrigger:

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

This example creates a Queue Storage trigger named MyQueueTrigger:

func new --template "Azure Queue Storage Trigger" --name MyQueueTrigger

The following considerations apply when adding functions:

• When you run func new without the --template option, you're prompted to choose a template.

• Use the func templates list command to see the complete list of available templates for your language.

• When you add a trigger that connects to a service, you'll also need to add an application setting that references a connection string or a managed identity to the local.settings.json file. Using app settings in this way prevents you from having to embed credentials in your code. For more information, see Work with app settings locally.

To learn more about the available options for the func new command, see the func new reference.

Add a binding to your function

Functions provides a set of service-specific input and output bindings, which make it easier for your function to connection to other Azure services without having to use the service-specific client SDKs. For more information, see Azure Functions triggers and bindings concepts.

To add an input or output binding to an existing function, you must manually update the function definition.

The following example shows the function definition after adding a Queue Storage output binding to an HTTP triggered function:

[FunctionName("HttpExample")]
public static async Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)] HttpRequest req, 
    [Queue("outqueue"),StorageAccount("AzureWebJobsStorage")] ICollector<string> msg, 
    ILogger log)

[Function("HttpExample")]
public static MultiResponse Run([HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequestData req,
    FunctionContext executionContext)
{

public class MultiResponse
{
    [QueueOutput("outqueue",Connection = "AzureWebJobsStorage")]
    public string[] Messages { get; set; }
    public HttpResponseData HttpResponse { get; set; }
}

@FunctionName("HttpExample")
public HttpResponseMessage run(
        @HttpTrigger(name = "req", methods = {HttpMethod.GET, HttpMethod.POST}, authLevel = AuthorizationLevel.ANONYMOUS) 
        HttpRequestMessage<Optional<String>> request, 
        @QueueOutput(name = "msg", queueName = "outqueue", 
        connection = "AzureWebJobsStorage") OutputBinding<String> msg, 
        final ExecutionContext context) {

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    },
    {
      "type": "queue",
      "direction": "out",
      "name": "msg",
      "queueName": "outqueue",
      "connection": "AzureWebJobsStorage"
    }
  ]
}

$outputMsg = $name
Push-OutputBinding -name msg -Value $outputMsg

@app.route(route="HttpExample")
@app.queue_output(arg_name="msg", queue_name="outqueue", connection="AzureWebJobsStorage")
def HttpExample(req: func.HttpRequest, msg: func.Out [func.QueueMessage]) -> func.HttpResponse:
    logging.info('Python HTTP trigger function processed a request.')

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    },
    {
      "type": "queue",
      "direction": "out",
      "name": "msg",
      "queueName": "outqueue",
      "connection": "AzureWebJobsStorage"
    }
  ]
}

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    },
    {
      "type": "queue",
      "direction": "out",
      "name": "msg",
      "queueName": "outqueue",
      "connection": "AzureWebJobsStorage"
    }
  ]
}

The following considerations apply when adding bindings to a function:

• When you add bindings that connect to a service, you must also add an application setting that references a connection string or managed identity to the local.settings.json file. For more information, see Work with app settings locally.

Start the Functions runtime

Before you can run or debug the functions in your project, you need to start the Functions host from the root directory of your project. The host enables triggers for all functions in the project. Use this command to start the local runtime:

mvn clean package 
mvn azure-functions:run

func start

npm install
npm start     

When the Functions host starts, it outputs a list of functions in the project, including the URLs of any HTTP-triggered functions, like in this example:

Found the following functions:
Host.Functions.MyHttpTrigger

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

Keep in mind the following considerations when running your functions locally:

• By default, authorization isn't enforced locally for HTTP endpoints. This means that all local HTTP requests are handled as authLevel = "anonymous". For more information, see Authorization level. You can use the --enableAuth option to require authorization when running locally. For more information, see func start

• You can use the local Azurite emulator when locally running functions that require access to Azure Storage services (Queue Storage, Blob Storage, and Table Storage) without having to connect to these services in Azure. When using local emulation, make sure to start Azurite before starting the local host (func.exe). For more information, see Local storage emulation.

• You can trigger non-HTTP functions locally without connecting to a live service. For more information, see Run a local function.

• When you include your Application Insights connection information in the local.settings.json file, local log data is written to the specific Application Insights instance. To keep local telemetry data separate from production data, consider using a separate Application Insights instance for development and testing.

Run a local function

With your local Functions host (func.exe) running, you can now trigger individual functions to run and debug your function code. The way in which you execute an individual function depends on its trigger type.

http://localhost:<PORT>/api/<FUNCTION_NAME>

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

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

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

http://localhost:<PORT>/admin/functions/<FUNCTION_NAME>

{
    "input": "<TRIGGER_INPUT>"
}

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

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

Publish to Azure

The Azure Functions Core Tools supports three types of deployment:

You must have either the Azure CLI or Azure PowerShell installed locally to be able to publish to Azure from Core Tools. By default, Core Tools uses these tools to authenticate with your Azure account.

If you don't have these tools installed, you need to instead get a valid access token to use during deployment. You can present an access token using the --access-token option in the deployment commands.

Deploy project files

func azure functionapp publish <FunctionAppName>

mvn azure-functions:deploy

Deploy containers

Core Tools lets you deploy your containerized function app to both managed Azure Container Apps environments and Kubernetes clusters that you manage.

func azurecontainerapps deploy --name <APP_NAME> --environment <ENVIRONMENT_NAME> --storage-account <STORAGE_CONNECTION> --resource-group <RESOURCE_GROUP> --image-name <IMAGE_NAME> [--registry-password] [--registry-server] [--registry-username]

func kubernetes deploy --name <DEPLOYMENT_NAME> --registry <REGISTRY_USERNAME> 

Local settings

When running in a function app in Azure, settings required by your functions are stored securely in app settings. During local development, these settings are instead added to the Values object in the local.settings.json file. The local.settings.json file also stores settings used by local development tools.

Because the local.settings.json may contain secrets, such as connection strings, you should never store it in a remote repository. To learn more about local settings, see Local settings file.

The following considerations apply when working with the local settings file:

• Because the local.settings.json may contain secrets, such as connection strings, you should never store it in a remote repository. Core Tools helps you encrypt this local settings file for improved security. For more information, see Local settings file. You can also encrypt the local.settings.json file for added security.

• By default, local settings aren't migrated automatically when the project is published to Azure. Use the --publish-local-settings option when you publish your project files to make sure these settings are added to the function app in Azure. Values in the ConnectionStrings section are never published. You can also upload settings from the local.settings.json file at any time.

• You can download and overwrite settings in your local.settings.json file with settings from your function app in Azure. For more information, see Download application settings.

• When no valid storage connection string is set for AzureWebJobsStorage and a local storage emulator isn't being used, an error is shown. You can use Core Tools to download a specific connection string from any of your Azure Storage accounts.

Download application settings

From the project root, use the following command to download all application settings from the myfunctionapp12345 app in Azure:

func azure functionapp fetch-app-settings myfunctionapp12345

This command overwrites any existing settings in the local.settings.json file with values from Azure. When not already present, new items are added to the collection. For more information, see the func azure functionapp fetch-app-settings command.

Download a storage connection string

Core Tools also make it easy to get the connection string of any storage account to which you have access. From the project root, use the following command to download the connection string from a storage account named mystorage12345.

func azure storage fetch-connection-string mystorage12345

This command adds a setting named mystorage12345_STORAGE to the local.settings.json file, which contains the connection string for the mystorage12345 account. For more information, see the func azure storage fetch-connection-string command.

For improved security during development, consider encrypting the local.settings.json file.

Upload local settings to Azure

When you publish your project files to Azure without using the --publish-local-settings option, settings in the local.settings.json file aren't set in your function app. You can always rerun the func azure functionapp publish with the --publish-settings-only option to upload just the settings without republishing the project files.

The following example uploads just settings from the Values collection in the local.settings.json file to the function app in Azure named myfunctionapp12345:

func azure functionapp publish myfunctionapp12345 --publish-settings-only

Encrypt the local settings file

To improve security of connection strings and other valuable data in your local settings, Core Tools lets you encrypt the local.settings.json file. When this file is encrypted, the runtime automatically decrypts the settings when needed the same way it does with application setting in Azure. You can also decrypt a locally encrypted file to work with the settings.

Use the following command to encrypt the local settings file for the project:

func settings encrypt

Use the following command to decrypt an encrypted local setting, so that you can work with it:

func settings decrypt

When the settings file is encrypted and decrypted, the file's IsEncrypted setting also gets updated.

Configure binding extensions

Functions triggers and bindings are implemented as .NET extension (NuGet) packages. To be able to use a specific binding extension, that extension must be installed in the project.

Core Tools versions

Major versions of Azure Functions Core Tools are linked to specific major versions of the Azure Functions runtime. For example, version 4.x of Core Tools supports version 4.x of the Functions runtime. This version is the recommended major version of both the Functions runtime and Core Tools. You can determine the latest release version of Core Tools in the Azure Functions Core Tools repository.

Run the following command to determine the version of your current Core Tools installation:

func --version

Unless otherwise noted, the examples in this article are for version 4.x.

The following considerations apply to Core Tools installations:

• You can only install one version of Core Tools on a given computer.

• When upgrading to the latest version of Core Tools, you should use the same method that you used for original installation to perform the upgrade. For example, if you used an MSI on Windows, uninstall the current MSI and install the latest one. Or if you used npm, rerun the npm install command.

• Version 2.x and 3.x of Core Tools were used with versions 2.x and 3.x of the Functions runtime, which have reached their end of support. For more information, see Azure Functions runtime versions overview.

Next steps

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