Limits and security
The current runtime boundaries, data isolation model, and execution allowances.
Execution limits
Each run gets its own sandbox with these limits. There is no separate CPU limit and no limit on the number of SDK calls: a run can compute and call storage, Shopify, secrets and HTTP for its whole deadline.
| Resource | Limit per run |
|---|---|
| Run deadline | 10 seconds |
| SDK calls (storage, Shopify, secrets, HTTP) | No limit; the deadline bounds a run |
| External requests, including redirect hops | 50, up to 5 seconds each |
| External request / response body | 64 KiB / 256 KiB |
| Bundled JavaScript source | 128 KiB |
| Input / document body | 64 KiB / 64 KiB |
| Result | 256 KiB |
| Documents per SDK list | 100, or 1 MiB of documents |
| Operations per atomic batch | 50 distinct documents |
| Secrets (per store) | 50, up to 8 KiB each |
A deadline stops further capability calls but doesn’t undo changes already committed, so write works that can safely run again.
Plan allowances
| Plan | Runs per billing period | Retained documents | Published admin pages |
|---|---|---|---|
| Starter ($19) | 10,000 | 2,000 | 2 |
| Growth ($39) | 50,000 | 10,000 | 5 |
| Scale ($79) | 250,000 | 50,000 | 15 |
Usage warns at 80% and 95% of each allowance. Automations run at most 6 at a time per store, and run logs and detailed errors are kept for seven days; run history, saved versions and records stay. Run allowances reset with the store’s Shopify billing period, and cover test and real runs from every entrypoint. Documents don’t reset; deleting a document frees its place. Redeploying or renaming a work doesn’t reset usage. Check Usage or get_usage for the store’s current allowances and what remains.
| On every plan | Limit |
|---|---|
| Document size | 64 KiB of JSON |
| Collections | 200 per store |
| External HTTPS requests | Included, up to 50 per run |
| Shopify GraphQL | Included, within the store’s approved permissions and Shopify’s own throttling |
| Responses served from cache | Included; they don’t use runs. Public GET works opt in |
Stored JSON is measured in UTF-8 bytes, and expired records count until cleanup removes them. A full document allowance stops new documents, but updates and deletes keep working. An atomic batch can change up to 50 documents. Littleworks also protects public endpoints from bursts of traffic; that protection is automatic and separate from plan allowances.
Isolation and permissions
Code runs in a separate sandbox with no platform secrets or database bindings. Littleworks supplies scoped capabilities for each invocation. Storage access is constrained to the current store and feature. Shopify calls require the work’s explicit permission and the app’s approved scopes.
Direct network access is blocked. Works use http.fetch() for public HTTPS APIs and shopify.admin.graphql or shopify.storefront.graphql for Shopify. Secrets work like an app’s environment variables: every work in the store can read them, and only the agents and people the merchant connects can deploy works. Works are plain JavaScript, and littleworks export writes every work’s source, the store’s records and its pages to files you keep (export).
Public endpoint responsibilities
Rate limits and input validation are automatic. Cached public reads are served to everyone who sends the same query, so never return personal data from a cached work. Customer and invitation modes validate identity or an action token before execution. Your work still enforces ownership and business rules. CORS is not authentication, and an order ID supplied by a visitor is not proof of purchase. See Customer access and invitations.
Building around the boundaries
Littleworks runs the backend of store features. For the things it doesn’t do itself, there’s usually a direct route:
| You need | How to build it |
|---|---|
| Files, such as artwork or photos | Store files in the merchant’s Shopify Files with shopify.files. A work issues an upload target, the browser uploads straight to Shopify, and a work saves the file and keeps its ID on a record. Needs Files access (write_files); images and files up to 20 MB, videos up to 1 GB. |
| Email, SMS or another service | Call its API with http.fetch, using a key from secrets. Included on every plan. For email, follow the transactional email and back-in-stock recipes: your provider sends, and the outbox makes sure nobody is emailed twice. |
| A service that uses OAuth | Store an API key or long-lived token as a secret. Littleworks doesn’t run per-user OAuth flows. |
| Work longer than one run | Queue background jobs: each run does one page or batch and continues with a cursor, or fans out keyed batches, with retries and at most 2 job runs at a time per store. For bulk Shopify writes, use mutations that take many items at once, such as inventorySetQuantities with 250 quantities a call. |
| npm packages or TypeScript | The CLI bundles them into one file before deploying. MCP clients deploy self-contained JavaScript. |
| Storefront pages and theme UI | Your theme renders them and calls a work for data. Agents use Shopify’s own theme tools for theme changes. |
| Signed-in customers on Hydrogen or another headless storefront | The storefront’s server signs a short customer assertion with a store secret and calls the work’s direct URL. See customer access. |
| Pages in Shopify admin | Views render native admin pages from a description of your records. |
| To start a Shopify Flow workflow | Start it from one of Shopify’s triggers and run a work from it. The work’s result returns to Flow for later steps. |
Not supported: private-network requests, streaming responses, HTML hosting, cookies and custom response headers. Read the connected store’s get_context for current capabilities before deploying.