Functions

Functions run your code on PubNub's global network. You avoid servers and extra latency from external callouts. Processing is low-latency and real-time.

PubNub offers Functions in two versions (v1 and v2) that differ in terms of scope, terminology, UI flow on the Admin Portal, and library or REST API access.

Function versions

This document details the UI for Functions v2 that are accessible for new PubNub Functions users. To learn about the differences between both versions, refer to the Functions v1 vs. v2 comparison.

The steps for creating a Function also differ depending on the version. For details, refer to Development Guidelines v2 and Development Guidelines v1.

Packages group related Functions. Revisions capture changes. Deploy Revisions to keysets.

Packages

Public Admin Portal demo

Want to browse through the Admin Portal without creating an account? Explore it through the Public Demo that shows examples of most PubNub features for transport and logistics use case.

Before creating a Function, you must create a Package for it.

Packages from scratch are labeled Custom. Packages from integrations are labeled Template.

Functions

Provide a Function name, an event type that triggers it, and a channel. You can use a 2-level wildcard, like foo.*. The asterisk (*) matches one segment, for example foo.bar.

Channel selection

Use wildcards to cover more channels. Functions v2 supports up to 5 deployments (free) or 30 (paid) per Package Revision across keysets.

Once a Package is created, you can also open its specific Revision and add or delete Functions to/from it.

Test Functions

The Debug tab in the Function's editor lets you test the Function by sending a sample payload and analyzing the response.

Export logs through Events & Actions

Any running Function publishes its logs to an internal blocks-output-* channel, like blocks-output-NSPiAuYKsWSxJl4yBn30 (you can find this channel name in the Console output). The channel name follows blocks-output-[unique-id].

The channel keeps the last 250 lines; new logs overwrite older ones.

To retain logs, export them with Events & Actions via Webhook or S3.

To do that, follow these steps:

1. Set up an event listener to listen for events on the internal channel. Provide the following configuration and enter the correct blocks-output-* channel from the Console output in the Condition value field.

   

2. Create either a Webhook or S3 action and add the created event listener to it.

   When configuring this action, you can use the Batching feature to send multiple events in a single request.

Revisions

A Package can have many Revisions (versions of the Package).

The first Revision is created automatically. Saving code or event type changes creates a new Revision.

Deployments

Deploy a Revision to run a Function. Test in one Revision; deploy another to production.

Select the keysets where the Functions run.

A Revision can deploy to up to 50 keysets. This is a fixed limit per Revision.

Permissions

Your level of access to Functions depends on the role you are assigned in the Admin Portal.

If you want to assign another user access to Functions on your account, you must assign them either the Functions developer or the Functions viewer role. This user must already have one of the standard roles assigned to their account: Account Admin, App Viewer, App Admin, Key Viewer, Key Admin.

See the permissions table below for allowed actions:

Permission	Functions developer	Functions viewer
View Packages	Yes	Yes
View Revisions	Yes	Yes
View deployments	Yes	Yes
Create Packages	Yes	No
Update Packages (rename)	Yes	No
Create Revisions	Yes	Yes
Update Revisions (rename)	Yes	No
Assign Revisions to keysets (create deployments)	Yes	No
Import Packages from the Integrations Catalog and assign to keysets (create deployments)	Yes	No
Manage secrets on keysets	Yes	Yes
Start deployments	Yes	No
Stop deployments	Yes	No
Rolling update deployments	Yes	No
Delete deployments	Yes	No
Delete Revision	Yes	No
Delete Package	Yes	No