Skip to content
The host/runtime that powers Azure Functions
C# HTML PowerShell Shell JavaScript Batchfile Other
Branch: dev
Clone or download
Type Name Latest commit message Commit time
Failed to load latest commit information.
.github/ISSUE_TEMPLATE Starting template Jun 27, 2019
.nuget Initial migration to .NET Core 2.0 Oct 11, 2017
.vscode add a launch.json for WebJobs.Script.WebHost Aug 26, 2019
build creating official ExtensionsMetadataGenerator build Feb 13, 2019
sample Add CancellationToken to ActionExtensions- Debouce API (#4643) Jul 11, 2019
schemas/json removing host.json schema from repo Dec 13, 2018
src Adding remote cert validation for seabreeze (#4937) Sep 20, 2019
test Adding remote cert validation for seabreeze (#4937) Sep 20, 2019
tools Increase PS and Java RPS thresholds Sep 6, 2019
.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 Include python in the dev docker file Aug 24, 2019
LICENSE.txt Fixing license file Oct 26, 2017
LICENSE_APACHE.txt Enabling buffering for all requests. Fixes #3765. Dec 12, 2018
NuGet.config Updating WebJobs SDK references to beta7 Jun 5, 2018 Remove preview tag from Python in Readme (#4933) Sep 16, 2019
WebJobs.Script.Tests.E2E.sln Throughput tests Oct 10, 2018
WebJobs.Script.sln fixing metadata to handle .NET Core 2.1+ function apps; adding loggin… Feb 11, 2019
appveyor.yml Fixing build configuration Jul 24, 2019
build.cmd Support WEBSITE_AUTH_ENCRYPTION_KEY and fix SA warning Nov 2, 2017
build.ps1 Remove "XDT_BITNESS" in "no-runtime" applicationHost.xdt Apr 30, 2019
check.ps1 Add check for Java (#3007) Jun 14, 2018 Installing .NET Core 2.1 on Linux Jun 5, 2018
omnisharp.json Disable script compilation in omnisharp Sep 17, 2019
run-tests.ps1 fixing metadata to handle .NET Core 2.1+ function apps; adding loggin… Feb 11, 2019
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. These differences are explained according to host version:

In V1, 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.

In V2, running a language out of process is no longer considered experimental. Out of process languages include JavaScript/Node.js (GA), Java (GA), Python (GA), and PowerShell (Preview). C# and F# are still run in process. For more information about Supported Languages, see this Microsoft Docs page.

Code Examples

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 PowerShell script that uses the same function definition, writing the incoming messages to blobs (it could process/modify the message in any way):

param([string] $workItem, $TriggerMetadata)
Write-Host "PowerShell queue trigger function processed work item: $workItem"
Push-OutputBinding -Name receipt -Value $workItem

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.

You can’t perform that action at this time.