EdgeWorkers

Using PowerShell to manage your EdgeWorkers, a platform for running JavaScript code at the edge, might seem like a strange choice, but the functions included in the Akamai.EdgeWorkers module can make your software lifecycle when developing your EdgeWorker code much easier. We have written in various features to reduce effort and toil, and allow you to focus on the javascript code without worrying about unduly about updating and deploying that code.

Name and Version Expansion

Just like in Property Manager and AppSec, the EdgeWorkers PowerShell module supports using names when interacting with EdgeWorkers by using -EdgeWorkerName rather than -EdgeWorkerID (which is also supported), and using the following keywords when referring to individual versions:

latest - The most recent version, assuming your EdgeWorker versions use semantic versioning
production - The production-active version
staging - The staging-active version

Since EdgeWorker versions come from a string in the bundle.json, it is possible to use labels which cannot be sorted. For example, if your three versions were apples, bananas and oranges, then sorting them will likely not produce the result you expect. Best to use versions in the form of major.minor.patch, e.g. 1.2.3 to take advantage of the automatic version selection in PowerShell.

CRUD

Create a new EdgeWorker uses the New-EdgeWorker function. You can specify your EdgeWorker's requirements as parameters, like this:

$CreateParams = @{
    EdgeWorkerName = "MyEdgeWorker"
    GroupID = 654321
    ResourceTierID = 100
    Description = "My EdgeWorker for testing"
}
New-EdgeWorker @CreateParams
 
edgeWorkerId     : 123456
name             : MyEdgeWorker
accountId        : A-B-ABCDE
groupId          : 654321
resourceTierId   : 100
description      : My EdgeWorker for testing
createdBy        : username
createdTime      : 20/08/2026 22:38:30
lastModifiedBy   : username
lastModifiedTime : 20/08/2026 22:38:30

You can then retrieve your EdgeWorker using Get-EdgeWorker, which can also list all EdgeWorkers in your account. Note that the output of Get-EdgeWorker is the same as what you get back from New-EdgeWorker, so if you working in a script it is good practice to assign the output of New-EdgeWorker to a variable, and then use that variable to retrieve the EdgeWorker later.

Get-EdgeWorker -EdgeWorkerName MyEdgeWorker
 
edgeWorkerId     : 123456
name             : MyEdgeWorker
accountId        : A-B-ABCDE
groupId          : 654321
resourceTierId   : 100
description      : My EdgeWorker for testing
createdBy        : username
createdTime      : 20/08/2026 22:38:30
lastModifiedBy   : username
lastModifiedTime : 20/08/2026 22:38:30

You can rename your EdgeWorker or move it to another group with Set-EdgeWorker, and you can delete it with Remove-EdgeWorker.

Version Management

This is the area where you will likely spend the bulk of your time when working with EdgeWorkers. Versions are created via the New-EdgeWorkerVersion command, which requires your code in one of two formats.

Firstly, you can provide a path to a tgz file (gzipped tarball), which contains your entire EdgeWorker in a compressed format.

New-EdgeWorkerVersion -EdgeWorkerName MyEdgeWorker -CodeBundle MyEdgeWorker.tgz

Alternatively, we have added capabilities into PowerShell to handle all the file compression and packaging for you, provided your system has the tar command locally.

Nearly all versions of MacOS and Linux come with tar preinstalled. Windows has done the same since Windows 10 version 1803 (the April 2018 update). If you do not have tar installed, the functions will throw an error and require you to bundle your code yourself.

Let's say we have the code for an edgeworker in a folder called /src. In which case you could run:

New-EdgeWorkerVersion -EdgeWorkerName MyEdgeWorker -CodeDirectory /src

PowerShell will then create a temporary tgz file, and upload that to Akamai for you.

Auto-Versioning

In the above examples, you may notice that we have not specified the version of the code we are uploading. You might assume that the version simply increments from the previously deployed version, as is the case with both Property Manager and AppSec. Instead, the version comes from the bundle.json file. However, it is very easy to forget to update this file when working on your JavaScript code, so we have added parameters to either increment the version automatically, or allow you to specify the version on the command line, which will then update the bundle.json file for you.

If you wish to auto-increment the version, provided you are using semantic versioning, you can use one of the following parameters:

-Major - Increments the major version, e.g. 1.2.3 becomes 2.0.0
-Minor - Increments the minor version, e.g. 1.2.3 becomes 1.3.0
-Patch - Increments the patch version, e.g. 1.2.3 becomes 1.2.4

Like this:

New-EdgeWorkerVersion -EdgeWorkerName MyEdgeWorker -CodeDirectory /src -Minor

Both the local copy and the one compressed into the tgz file will be updated with the new version number.

Alternatively, if you wish to provide the version number yourself, such as might be the case when using npm to increment the package version, you can use the -Version parameter:

New-EdgeWorkerVersion -EdgeWorkerName MyEdgeWorker -CodeDirectory /src -Version 1.2.3

Again, the bundle.json file will be updated.

Validation

If you wish to validate that your EdgeWorker code is valid before creating a new version, you can use the Test-EdgeWorkerCodeBundle command. This will check that your code is valid, and that it meets the requirements for an EdgeWorker. You can provide either a tgz file or a directory, just like with New-EdgeWorkerVersion.

Test-EdgeWorkerCodeBundle -CodeDirectory /src

Deploying your version

Once you have created a new version of your EdgeWorker, you can deploy it to either Staging or Production using the Deploy-EdgeWorker command. You will need to provide the network (whose values you can tab-complete from either STAGING or PRODUCTION), as well as taking advantage of the name and version expansion features mentioned above.

Deploy-EdgeWorker -EdgeWorkerName MyEdgeWorker -Version latest -Network STAGING

Enhanced Debugging

Once your EdgeWorker is deployed, you will likely want to test the code. EdgeWorkers comes with an enhanced debug feature which requires a JWT token be sent along with your request using the header akamai-ew-trace. The value of this token can be generated using New-EdgeWorkerAuthToken. You must provide the value of the -Expiry parameter, which represents the number of minutes the token will be valid for, up to a maximum of 720 (12 hours). You can also limit the scope of the token to a given set of hostnames, otherwise your token will apply to any hostname in an entire account.

Only users with the Admin role can generate account-wide tokens, so using the -Hostnames parameter is required for users with lower permissions.

$Token = New-EdgeWorkerAuthToken -Expiry 60 -Hostnames "www.example.com"
 
curl -H "akamai-ew-trace: $Token" -H Pragma:akamai-x-ew-debug,akamai-x-ew-debug-subs,akamai-x-ew-debug-rp https://www.example.com/path/to/your/edgeworker

Increasing Log Levels

When using enhanced debugging as above, you always receive EW logs at the highest level. However, more and more often customers are using DataStream to ship their EdgeWorker logs to their own log analysis platform. When setting up Datastream, the provided log level defaults to error, but can also be set in the bundle.json. However, there is also an API endpoint to set the log level for a period without deploying a new version.

New-EdgeWorkerLoggingOverride -EdgeWorkerName MyEdgeWorker -Network PRODUCTION -Level DEBUG -Timeout 2026-08-20T22:38:30Z

Once this is live, the log level dispatched through Datastream will be at the DEBUG level, and will remain so until the timeout is reached. You can also use Get-EdgeWorkerLoggingOverride to see what overrides are currently in place.

Edge DNS Global Traffic Manager (GTM)