The host/runtime that powers Azure Functions
Switch branches/tags
Clone or download
Failed to load latest commit information.
.nuget Initial migration to .NET Core 2.0 Oct 11, 2017
build Updating package EULA link Oct 8, 2018
sample Add support for identity bindings and samples Oct 26, 2018
schemas/json Removing host id property from host.json Sep 7, 2018
src Relaxing EF dependency restricion Nov 17, 2018
test updating nugets; using new ISdkVersionProvider Nov 16, 2018
tools Fixing metadata generator target file: copy relevant runtime binaries Sep 13, 2018
.gitattributes Add .gitattribute Feb 4, 2016
.gitignore Reenable http throttles (#2945) Aug 22, 2018 Update Aug 1, 2018
CustomDictionary.xml If a key is undecryptable, rename it, log it, regnerate it . Fixes #2072 Jan 4, 2018
Dockerfile Add a Dockerfile for building current HEAD Jul 18, 2018
FailingIntegrationTests.playlist Fixes after rebase Oct 12, 2017 Removing pre-release suffix Sep 18, 2018
LICENSE.txt Fixing license file Oct 26, 2017
NuGet.config Updating WebJobs SDK references to beta7 Jun 5, 2018 Remove mention of webjobs dashboard from readme Jul 2, 2018
WebJobs.Script.Tests.E2E.sln Throughput tests Oct 10, 2018
WebJobs.Script.Tests.Perf.sln Perf tests appveyor integration Oct 18, 2018
WebJobs.Script.sln Add support for identity bindings and samples Oct 26, 2018
appveyor-perf.yml Perf tests appveyor integration Oct 18, 2018
appveyor.yml Updating SDK references and bumping version information Sep 11, 2018
build.cmd Support WEBSITE_AUTH_ENCRYPTION_KEY and fix SA warning Nov 2, 2017
build.ps1 Updating ANCM to 2.1.0-a-oob-2-1-oob-17297 Oct 12, 2018
check.ps1 Add check for Java (#3007) Jun 14, 2018 Installing .NET Core 2.1 on Linux Jun 5, 2018
run-tests.ps1 Reinitialize containers on restart Jun 13, 2018
src.ruleset Consolidating ruleset files. Cleaning up warnings Aug 13, 2018
stylecop.json Initial migration to .NET Core 2.0 Oct 11, 2017

Azure Functions Logo

Branch Status
master Build status
dev Build status
v1.x Build status


This repo contains libraries that enable a light-weight scripting model for the Azure WebJobs SDK. You simply provide job function scripts written in various languages (e.g. Javascript/Node.js, C#, Python, F#, PowerShell, PHP, CMD, BAT, BASH scripts, etc.) along with a simple function.json metadata file that indicates how those functions should be invoked, and the scripting library does the work necessary to plug those scripts into the Azure WebJobs SDK runtime.

These libraries are the runtime used by Azure Functions. The runtime builds upon the tried and true Azure WebJobs SDK - this library just layers on top to allow you to "script the WebJobs SDK".

An important note on language support levels - while many languages are supported, their level of support differs in important ways, making some languages more suitable than others for certain workloads. The first class languages are C#, F# and Javascript/Node.js. Functions written in these languages are run in process and are suitable for any workload. The remaining languages are considered experimental. Functions written in these languages are scripts that are run out of process. While there are many scenarios where this is acceptable, it won't be acceptable for high load scenarios where the overhead of a new process for each invocation won't scale.

As an example, here's a simple Node.js function that receives a queue message and writes that message to Azure Blob storage:

module.exports = function (context, workItem) {
    context.log('Node.js queue trigger function processed work item ',;
    context.bindings.receipt = workItem;

And here's the corresponding function.json file which includes a trigger input binding that instructs the runtime to invoke this function whenever a new queue message is added to the samples-workitems queue:

  "bindings": [
      "type": "queueTrigger",
      "direction": "in",
      "queueName": "samples-workitems"
      "type": "blob",
      "name": "receipt",
      "direction": "out",
      "path": "samples-workitems/{id}"

The receipt blob output binding that was referenced in the code above is also shown. Note that the blob binding path samples-workitems/{id} includes a parameter {id}. The runtime will bind this to the id property of the incoming JSON message. Functions can be just a single script file, or can include additional files/content. For example, a Node.js function might include a node_modules folder, multiple .js files, etc. A PowerShell function might include and load additional companion scripts.

Here's a Windows Batch script that uses the same function definition, writing the incoming messages to blobs (it could process/modify the message in any way):

SET /p workItem=<%input%
echo Windows Batch script processed work item '%workItem%'
echo %workItem% > %receipt%

And here's a Python function for the same function definition doing the same thing:

import os

# read the queue message and write to stdout
workItem = open(os.environ['input']).read()
message = "Python script processed work item '{0}'".format(workItem)

# write to the output binding
f = open(os.environ['receipt'], 'w')

Note that for all script types other than Node.js, binding inputs are made available to the script via environment variables, and output logs is written via STDOUT. You can see more script language examples here.

The samples also includes a canonical image resize sample. This sample demonstrates both input and output bindings. Here's the function.json:

  "bindings": [
      "type": "blobTrigger",
      "name": "original",
      "direction": "in",
      "path": "images-original/{name}"
      "type": "blob",
      "name": "resized",
      "direction": "out",
      "path": "images-resized/{name}"

When the script is triggered by a new image in images-original, the input binding reads the original image from blob storage (binding to the name property from the blob path), sets up the output binding, and invokes the script. Here's the batch script (resize.bat):

.\Resizer\Resizer.exe %original% %resized% 200

Using Resizer.exe which is part of the function content, the operation is a simple one-liner. The bound paths set up by the runtime are passed into the resizer, the resizer processes the image, and writes the result to %resized%. The ouput binding uploads the image written to %resized% to blob storage.

On startup, the script runtime loads all scripts and metadata files and begins listening for events (e.g. new Queue messages, Blobs, etc.). Functions are invoked automatically when their trigger events are received. Virtually all of the WebJobs SDK triggers (including Extensions) are available for scripting. Most of the configuration options found in the WebJobs SDK can also be specified via json metadata.

When hosted in an Azure Web App this means there is no compilation + publish step required. Simply by modifying a script file, the runtime will load the new script content + metadata, and the changes are live. Scripts and their metadata can be modified quickly on the fly in a browser editor (e.g. in a first class UI or in the Kudu Console) and the changes take effect immediately.

The Script library is available as a Nuget package (Microsoft.Azure.WebJobs.Script). Currently this package is available on the App Service Myget feed.

Please see the Wiki for more information on how to use and deploy the library, and also please log any issues/feedback on our issues list and we'll investigate.


This project is under the benevolent umbrella of the .NET Foundation and is licensed under the MIT License

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact with any additional questions or comments.


See the getting help section in the wiki.