App Platform Overview

The Lombok App Platform lets you build custom TypeScript applications that run alongside your storage infrastructure. Whether you need automated file processing, custom workflows, integrations with external services, or entirely new features built on top of your data, the app platform gives you a programmable compute layer with full access to Lombok’s APIs.

You write standard TypeScript — the framework you already know — and Lombok handles deployment, scaling, event routing, and infrastructure management. Your apps run in isolated environments with secure access to folders, files, users, and storage provisions. The result is a serverless-style development experience without vendor lock-in, running on infrastructure you control.

If you’re new to Lombok, start with the Core Concepts page to understand how apps fit into the broader platform architecture.

Deployment Models

Lombok supports two deployment models for apps, each optimized for different use cases. Choose the model that best fits your infrastructure requirements and operational preferences.

Remote Standalone Apps

A remote standalone app is an independent application that you host and manage separately from your Lombok instance. It communicates with Lombok via WebSocket to receive events and access Lombok’s APIs.

How it works: Your app runs on your own server, container platform, or cloud provider. When deployed, it establishes a persistent WebSocket connection to your Lombok instance. Lombok sends events (file uploads, deletions, scheduled triggers) over the WebSocket, and your app can call back to Lombok’s APIs to read files, create folders, or manage users.

Use case: Choose remote standalone when you need full control over hosting, want to run on custom infrastructure, need to scale independently of Lombok, or integrate with other services in your existing environment. This model is ideal for complex applications with significant compute requirements, external integrations, or when you already have a hosting infrastructure you want to use.

Learn more: App Configuration Guide

Managed Local Apps

A managed local app consists of prebuilt UIs and/or worker scripts that are packaged and installed directly on your Lombok instance. Lombok manages the installation, updates, and lifecycle of these apps.

How it works: You package your app as a bundle (TypeScript source, assets, configuration) and distribute it through the Lombok app directory or direct installation. Users install the app through the Lombok admin interface, and Lombok unpacks, validates, and runs the app’s code within the main application process. Your app’s workers are registered automatically, and any UI components are embedded in Lombok’s interface.

Use case: Choose managed local when you want simplicity, automatic updates, and minimal infrastructure overhead. This model is ideal for simpler apps, reusable components that multiple users can install, and when you want the app to feel like a native part of Lombok. Think plugins or extensions rather than standalone services.

Learn more: App Configuration Guide

Integration Points

Lombok apps can integrate with the platform in three primary ways, depending on your needs. Most apps use a combination of these integration points.

UI Integration

Apps can embed custom user interfaces directly into Lombok’s web interface, appearing as menu items in the sidebar. When users click your app’s menu item, Lombok loads your custom UI in the main content area, providing a seamless experience that feels native to the platform.

Your UI is built with standard web technologies (HTML, CSS, TypeScript) and has access to Lombok’s APIs through the app SDK. You can build dashboards, administrative tools, custom file viewers, or any interface that makes sense for your app’s functionality.

Learn more: UI Integration Guide

Asynchronous Operations (Tasks)

Tasks are long-running or user-approved operations that run asynchronously. Your app can create custom task types that appear in Lombok’s task queue, where users can monitor progress, approve pending tasks, or cancel running operations.

Tasks are event-triggered — when a file is uploaded, a folder is created, or a schedule fires, your app’s task handler runs. Tasks support progress tracking, require user approval (optional), and can run for extended periods without blocking the UI. Use tasks for file processing pipelines, batch operations, data migrations, or any workflow that needs visibility and user control.

Learn more: Events & Tasks Documentation

Synchronous Operations (Workers)

Workers are TypeScript functions that execute synchronously in response to events or scheduled triggers. Unlike tasks, workers are lightweight, fast-executing functions that run immediately when triggered and return results directly to the caller.

Workers are ideal for real-time operations: validating file uploads before they’re saved, transforming data on-the-fly, responding to API requests, or running scheduled maintenance. You define workers in your app code, specify which events trigger them, and Lombok handles routing, execution, and error handling.

Learn more: Worker Scripts Guide

Getting Started

Ready to build your first Lombok app? Start with these steps:

1. Understand configuration — Learn about the config.json file that defines your app’s metadata, permissions, and entry points in the Configuration Guide.

2. Start simple — Build a basic worker that reacts to file uploads before attempting a full app with UI and tasks. Workers are the easiest way to get familiar with Lombok’s event system and APIs.

3. Review concepts — Make sure you understand folders, storage provisions, apps, and workers at a conceptual level before diving into implementation details.

4. Explore examples — Check the Worker Scripts Guide for practical code examples you can use as starting points.

The app platform is designed to feel familiar if you’ve used serverless functions, webhooks, or browser extensions. You bring your TypeScript skills, and Lombok provides the infrastructure, APIs, and event system to build on top of your storage layer.