Local Storage is the tenant-local file space available inside Jetstack. It is the place where the tenant can store arbitrary local files and directories for operational, integration, and implementation purposes.
Think of it as the tenant’s built-in filesystem workspace inside the platform.
This chapter focuses on the Local area of Local Storage. The same screen also exposes logs, but logs are a different operational surface with stricter interaction limits.
Local Storage gives a tenant a file space that is:
This makes it useful not only for storing files, but also for building reusable implementation assets that belong to the tenant rather than to the product codebase.
The most useful way to understand Local Storage is this:
Use Local Storage when the tenant needs a real file space. Do not use it as a replacement for structured object data.
Local AreaThe Local tab is the tenant file space rooted at the tenant’s local storage directory.
What it supports:
In practice, this is a full file-management workspace for the tenant, not just a read-only browser.
Local Storage comes with a fully fledged web administration UI based on the platform’s code-editor style file browser.
That UI supports:
This matters because Local Storage is not just a backend capability exposed to automations. It is also an administrator-facing management tool.
Typical Local Storage contents include:
The system is especially useful when a tenant needs a file that should be available to automations or custom PHP logic without turning that file into a media object or codebase customization.
Local Storage is available to automations.
In the current codebase, the automation layer includes local-file actions such as:
What this means in practice:
This makes Local Storage a practical companion to automation workflows.
Use Local Storage from automations when you need to:
One of the most important advanced use cases is storing reusable PHP code files in Local Storage and then loading them from custom PHP scripts.
This is useful because it lets you:
Typical examples:
include, include_once, require, And require_onceCustom PHP scripts can load reusable files from Local Storage using:
includeinclude_oncerequirerequire_onceThis is the key operational rule:
That means if a custom PHP script includes a relative file name, Jetstack resolves it inside the tenant-local filesystem context rather than against the product repository.
Use it as if your reusable PHP library files live under the Local Storage root.
For example, if the tenant stores helper files like:
local/lib/common.phplocal/lib/formatters.phplocal/integrations/crm.phpthen custom PHP logic can load them from the tenant-local context with relative references rooted in Local Storage.
The runtime also supports the normal PHP include semantics of resolving relative to the currently executing local file when appropriate. In practice, that means:
For implementers, the safe mental model is:
This pattern helps when:
Instead of duplicating the same helper function in many places, place it in Local Storage once and include it where needed.
Local Storage belongs to the tenant. Files stored there are not the same thing as:
That distinction matters because Local Storage is best treated as tenant-managed filesystem space, not as a replacement for every other extension mechanism.
The Local Storage screen also includes a logs browser, but the two tabs are intentionally different.
LocalThis is the editable tenant file space.
It supports active file management such as:
LogsThis is a constrained operational inspection surface for tenant logs.
It is more limited because log browsing has a different operational risk profile than ordinary local file management.
Suppose several automations need the same helper functions for preparing payloads for an external API.
Use this pattern:
lib/api.include_once or require_once.This keeps tenant scripting more maintainable and easier to review.
lib, helpers, or integrations.include_once or require_once for shared helper libraries to avoid duplicate loading.