Local Storage

What It Is

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.

Why It Matters

Local Storage gives a tenant a file space that is:

  • tenant-scoped
  • directory-based
  • available through a full web administration UI
  • accessible from automations and internal scripting flows

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.

Mental Model

The most useful way to understand Local Storage is this:

  • Media Files are for managed file/content workflows exposed as platform data.
  • Local Storage is for tenant-owned filesystem assets and operational files.

Use Local Storage when the tenant needs a real file space. Do not use it as a replacement for structured object data.

The Local Area

The Local tab is the tenant file space rooted at the tenant’s local storage directory.

What it supports:

  • files
  • directories
  • nested directory trees
  • text-file editing
  • file upload
  • folder upload
  • moving and renaming nodes
  • deleting files and folders
  • downloading files and folders

In practice, this is a full file-management workspace for the tenant, not just a read-only browser.

Web Administration UI

Local Storage comes with a fully fledged web administration UI based on the platform’s code-editor style file browser.

That UI supports:

  • browsing directories
  • navigating into subdirectories
  • seeing the current location
  • creating files
  • creating folders
  • uploading files
  • uploading full folders
  • drag-and-drop upload
  • renaming files
  • renaming folders
  • editing text files directly
  • moving files and folders
  • deleting files and folders
  • downloading files
  • downloading folders

This matters because Local Storage is not just a backend capability exposed to automations. It is also an administrator-facing management tool.

What You Can Store There

Typical Local Storage contents include:

  • exported data snapshots
  • generated text files
  • integration helper files
  • uploaded reference files for scripts
  • reusable code libraries
  • tenant-specific configuration fragments
  • temporary operational assets that need to stay in tenant space

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.

Access From Automations

Local Storage is available to automations.

In the current codebase, the automation layer includes local-file actions such as:

  • store a local file
  • write to a local file
  • read a local file
  • download a file for the user

What this means in practice:

  • an automation can create or update files in local storage
  • an automation can read files back later
  • automations can use local storage as a simple persistence layer for generated artifacts

This makes Local Storage a practical companion to automation workflows.

Common Automation Use Cases

Use Local Storage from automations when you need to:

  • dump processed data into files
  • persist generated text or JSON for later reuse
  • store exported outputs before another step consumes them
  • cache tenant-specific helper assets
  • create intermediate files that are later downloaded or read by another automation

Reusable PHP Libraries

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:

  • keep helper functions in shared files
  • avoid repeating the same PHP utility code in several automations or script blocks
  • build a tenant-local library layer without changing the main application code

Typical examples:

  • shared array helpers
  • formatting helpers
  • API wrapper helpers
  • validation helpers
  • mapping tables expressed as PHP structures

Using include, include_once, require, And require_once

Custom PHP scripts can load reusable files from Local Storage using:

  • include
  • include_once
  • require
  • require_once

This is the key operational rule:

  • the default root for these functions is the root of the tenant Local Storage

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.

Practical Include Model

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.php
  • local/lib/formatters.php
  • local/integrations/crm.php

then 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:

  • the overall execution context is the tenant Local Storage root
  • nested includes can behave relative to the current local file or its directory

For implementers, the safe mental model is:

  • treat Local Storage as the include root
  • organize reusable code files into clear subdirectories

Why This Is Useful

This pattern helps when:

  • several automations use the same helper logic
  • the same utility code should be reused in canvas PHP actions and automation PHP actions
  • the tenant needs maintainable custom scripting without copying code block by block

Instead of duplicating the same helper function in many places, place it in Local Storage once and include it where needed.

Important Scope Boundary

Local Storage belongs to the tenant. Files stored there are not the same thing as:

  • product source files
  • platform plugins
  • media-library records
  • customization templates
  • customization scripts under the dedicated customization area

That distinction matters because Local Storage is best treated as tenant-managed filesystem space, not as a replacement for every other extension mechanism.

Local Versus Logs

The Local Storage screen also includes a logs browser, but the two tabs are intentionally different.

Local

This is the editable tenant file space.

It supports active file management such as:

  • creating
  • uploading
  • editing
  • moving
  • deleting

Logs

This 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.

Example

Suppose several automations need the same helper functions for preparing payloads for an external API.

Use this pattern:

  1. Open Local Storage.
  2. Create a directory such as lib/api.
  3. Create a reusable PHP helper file there.
  4. In each custom PHP automation or script block, load the helper file with include_once or require_once.
  5. Keep all shared helper updates in that one local file instead of repeating them across actions.

This keeps tenant scripting more maintainable and easier to review.

Best Practices

  • Treat Local Storage as tenant-owned implementation file space, not as core business data.
  • Use directories intentionally so reusable code and generated outputs stay organized.
  • Put shared PHP helpers into clearly named library folders such as lib, helpers, or integrations.
  • Prefer include_once or require_once for shared helper libraries to avoid duplicate loading.
  • Use automations to write generated artifacts to Local Storage when those artifacts need to be reused later.
  • Do not turn Local Storage into an unmanaged document repository when Media Files or modeled objects would be clearer.
Previous← Links And PermalinksNextMedia Files →