Extension and Cloud Function Hosting
Emporix offers a built-in hosting model for custom extensions and cloud functions. Learn how the hosting works, what you can deploy, and how to manage the full deployment lifecycle.
Emporix provides a built-in, secure, and scalable hosting environment for custom extensions and cloud functions built on top of the Emporix Management Dashboard. Instead of maintaining your own cloud infrastructure, you can deploy and operate your custom code directly within the Emporix environment — with versioning, rollback, monitoring, and tenant isolation included out of the box.
Hosting of the extensions and cloud functions is not included in standard billing plans and is billed separately on a pay-as-you-go basis. If you're interested in getting access to the feature, contact the Sales Team.
How it works
The hosting model is project-based. It means that each tenant initializes a single hosting project as a one-time action. The project receives a unique Project ID and acts as the container for all hosted extensions and cloud functions on that tenant.
Emporix supports lazy hosting, which means no pre-configuration is required per tenant before the project is initialized. Once the project is set up, you can add any number of extensions and cloud functions to it.
Each hosted resource follows the same lifecycle:
You upload the code either from a GitHub repository or as a
zip/tar.gzarchive.The system automatically triggers a build process.
A successful build produces a versioned release that is immediately available for use.
For extensions hosting — all previous releases are retained, enabling rollback to any earlier version at any time.
You can delete a hosted cloud function from Administration -> Hosting — see Hosting.
What you can host
Extensions
Extensions are custom UI add-ons built on the MD Module Template, which is based on the module federation concept. A hosted extension integrates directly into the Emporix Management Dashboard and can be registered in one of two ways:
As a module — visible in the Extensions section of the Management Dashboard.
As a perspective — accessible with a dedicated URL path in the Dashboard navigation.
Each extension is identified by a unique Hosting ID, which becomes part of its hosting URL. The ID is limited to 41 characters to ensure that the tenant name, a hyphen, and the ID together remain within the 63-character limit for a hostname label. Display names can be localized to support multiple languages.
The Emporix infrastructure supports up to 20 extensions per hosting project.
Cloud functions
Cloud functions are serverless units of custom logic that can be triggered by events, Emporix APIs, or other platform processes. Unlike extensions, they are not UI components; they operate in the background and can be exposed in the Partner Library or consumed through custom API integrations. You can also use hosted cloud functions as tools on a dynamic MCP server, so AI agents can call your custom business logic.
Supported runtimes:
Node.js 24
Python 3.14
When you create a cloud function, you can add an optional localized Description and Tags. You can edit or clear those fields after the function is created. For the create and edit steps, see Hosting.
Cloud functions support environment variables, which can be defined as key-value pairs and used within the function code to securely decode credentials and configuration data.
Full invocation logs are available in the hosting details of each cloud function, showing when and how it was called and what the outcome was.
Example cloud function
Here is the example of a simple cloud function that returns a welcome message and the headers injected by Emporix.
Deployment and versioning
Every deployment — whether an initial upload or an update — triggers a build. The Build History tracks all builds with the following details: deployment ID, build ID, status, and timeline. For a cloud function, the details also include the deployer's first and last name when that name is available.
For extensions, all published versions are retained in the Releases panel. Each release shows its version ID, status, and timeline. If a new deployment introduces a regression, you can use the Rollback option to revert to any previous release — this results in the release of the selected version.
Cloud functions do not use rollback from Releases. From Build History, you can use Redeploy on a prior uploaded package. That creates a new deployment; the original row remains. For the operator steps, see Hosting.
Invoking cloud functions
Once you have enabled a cloud function hosting in Emporix, you can call the cloud function within your integration through API.
HTTP Methods
To invoke a cloud function, send an HTTP request to the function endpoint. Standard HTTP methods are available, so depending on what you need, you can call one of the following: POST, GET, PUT, DELETE.
Endpoint path
The root endpoint path:
If your cloud function exposes internal endpoints in addition, you can extend the path. For example:
Authentication and authorization
All the requests are routed through the Emporix platform. This means that the platform validates the provided tokens (service, customer, or anonymous). You do not need to implement any additional token validation inside your cloud function.
Request headers
Emporix enriches each request with additional headers that can be used within your function:
emporix-token
The token used for this invocation. Reuse it to call Emporix APIs.
HTTP agent call — reflects the caller.
Commerce event — generated from the agent's Event Scopes.
External MCP client — generated from the scopes assigned to the MCP API key.
emporix-tenant
Always set. Identifies the tenant that invoked the function.
emporix-scopes
The scopes assigned to that token. Use this header to see which resources the function can access.
emporix-user-id
Set for employee tokens on HTTP agent calls and for customer tokens. Not set for service tokens, commerce events, or external MCP clients.
emporix-session-id
Set when the function runs inside an agent session.
emporix-legal-entity-id
Set only for customer tokens when the customer is assigned to a legal entity. Not set for service tokens, commerce events, or external MCP clients.
Environment variables
If your cloud function uses environment variables, you can access them in your code as follows:
For example, process.env.client_id.
Example
See the example request calling a cloud function:
Last updated
Was this helpful?