What are the resource limits for a Shopify Function in 2026?

Each Function execution is bounded by 11 million WebAssembly instructions (for carts up to 200 line items; the budget scales for larger carts), a 256 kB compiled binary, 10,000 kB of runtime linear memory, 512 kB of stack memory, 128 kB of input, and 20 kB of output. Crucially, the limit is instruction count, not wall-clock time. Functions cannot use the network, filesystem, randomness, or current time.

Should I write Shopify Functions in Rust or JavaScript?

For complex logic (cart transforms with multi-line discounts, B2B pricing rules, fulfilment constraints) Rust produces smaller binaries and lower instruction counts. For simple validation or single-line discounts, JavaScript via the Javy runtime is sufficient and easier for teams to maintain. Most agencies pick Rust by default; teams without Rust experience often start in JavaScript and rewrite a hot path in Rust only when the instruction limit forces the issue.

How do I test Shopify Functions before deploying to production?

Use the Shopify CLI three-step pattern: (1) shopify app function build to compile the Wasm artefact, (2) shopify app function run --input=fixture.json --export=run to execute against a captured input, (3) shopify app function schema --stdout to verify the schema matches the version your store runs. Maintain a library of input fixtures covering edge cases (empty carts, international currencies, B2B catalogues) and run all of them in CI before any deploy.

Shopify Functions in Production 2026: 5 Patterns That Scale

Shopify Functions have transitioned from a technical preview to the standard for backend logic customisation on Shopify Plus. For engineering teams moving away from the legacy Script Editor, the shift represents a move from a restricted Ruby environment to a WebAssembly (WASM) architecture that demands more rigorous CI/CD practices. This shopify functions production guide covers the patterns that have held up for us when testing, deploying, and maintaining Functions in high-volume environments. Every limit quoted below was re-verified against the Function APIs reference in September 2026 (2026-07 is the latest stable Function API version, with 2026-10 in release candidate). One availability rule first: public App Store apps can ship Functions to stores on any plan, but custom apps with Functions run only on Shopify Plus.

The Shift to Local-First Development and MCP

The developer experience for Shopify Functions changed with the arrival of the Model Context Protocol (MCP) server for the Shopify Dev Assistant. It moves the work into the editor: developers query documentation and API schemas directly through their IDE context. The shopify.dev MCP server takes most of the friction out of looking up GraphQL schema definitions for the Input and Output objects required by Functions. That helps most when you are working with Polaris web components or Liquid logic within the broader app context.

The initial boilerplate is where most teams stall. The MCP server helps by providing a structured way to interact with the Shopify CLI, allowing for faster generation of Function extensions that adhere to current best practices. These tools speed up development. They do not replace a local test suite. Teams that lean on the Dev Assistant alone, with no local unit tests, get longer feedback loops and more frequent deployment failures.

Binary Testing and Validation Patterns

One of the most significant recent improvements in the ecosystem is support for binary testing. Traditionally, developers tested the source code (Rust or JavaScript) before compilation. While useful, this does not account for the behaviour of the final WASM binary. Binary testing matters because it validates the exact artifact that will run on Shopify's infrastructure. Discrepancies do turn up between the source-level logic and the compiled WASM, especially when dealing with complex memory management in Rust or the Javy runtime in JavaScript.

Our testing runs in tiers. First, unit tests cover the core business logic in the source language. Second, we use the Shopify CLI to run tests against the compiled .wasm file using mock JSON inputs (shopify app function build, then shopify app function run --input fixture.json --export run). The testing and debugging guide also covers shopify app function replay, which re-runs a real execution captured from app dev by its log identifier; since CLI 4.7.0 (August 2026) app function run can also profile the run, which is the fastest way to find the loop that is eating the instruction budget. This ensures that the input transformation and the output response match the expected GraphQL schema. This catches the schema mismatches that unit tests often miss. For teams managing complex discount logic or cart transforms, we recommend maintaining a library of JSON input snapshots that represent various edge cases, such as empty carts, international currencies, or specific customer tags.

Production Readiness Checklist

WASM Payload Size: Shopify caps the compiled binary at 256 kB. Aim for under 200 kB to leave headroom for future logic without triggering binary-bloat refactors.
Instruction Count: Each Function execution is bounded by 11 million WebAssembly instructions, not wall-clock time. The Shopify CLI reports your consumption per test run; complex loops over large cart arrays can approach this threshold and the only fix is algorithmic.
Graceful Failure: Implement logic to return a neutral output (e.g., no discount) if the Function encounters an unexpected input, rather than throwing an error.
Metaobject Caching: If using metaobjects for configuration, ensure the data structure is optimised for the Function's input query.
Logging Strategy: Use STDOUT for debugging in development, but plan for production, where logs are truncated at 1 kB per execution.

Metaobjects and Cart Metafields

A common challenge in production is making Functions dynamic without requiring a code redeploy for every configuration change. Metaobject access inside Functions changed the self-service story for merchants. By storing configuration data (tiered discount thresholds, B2B pricing rules) in metaobjects, we allow merchants to update logic via the Shopify Admin while the Function remains static.

Reading cart metafields directly from Functions and Checkout UI extensions also simplified how we pass data through the checkout flow. For instance, if a customer selects a specific delivery date or packaging preference, that data can be stored in a cart metafield and then read by a Delivery Customisation Function to adjust shipping options. The pattern shows up in bespoke gift-wrapping services or complex shipping logic where the standard Shopify shipping rates are insufficient. For a deeper look at how these patterns integrate with broader automation, see our guide on Shopify MCP production patterns.

Versioning and the functionHandle Pattern

Managing updates to Functions in a live production environment requires careful versioning, and that starts with the API version: Function APIs are versioned quarterly like the rest of the platform, so pin api_version in shopify.extension.toml deliberately and regenerate the schema and types (shopify app function schema, shopify app function typegen) when you move it. The introduction of functionHandle has provided a more reliable way to reference specific Functions within the cart and checkout. Handles instead of hardcoded IDs make it easier to manage deployments across multiple environments (staging vs. production).

For updates, a "blue-green" deployment is the safest approach we know. Instead of updating an existing Function, we deploy the new version as a separate extension, test it in a development store, and then update the app configuration to point to the new functionHandle. This allows for an immediate rollback if the new version exhibits unexpected behaviour in production. Merchants should skip automated auto-updates for Functions that handle core revenue logic, such as discounts or payment customisations, in favour of a manual, verified release process.

Performance and Execution Constraints

Shopify Functions operate under strict resource limits, not time limits. Each Function execution is bounded to 11 million WebAssembly instructions (for carts up to 200 line items; the budget scales proportionally for larger carts), 10,000 kB of runtime linear memory, 512 kB of stack, a 256 kB compiled binary, 128 kB of input, and 20 kB of output. Wall-clock time is not the constraint; instruction count is, and the dynamic limits (instructions, input, output) are the ones that scale with cart size while binary, memory, stack, and the 1 kB log cap stay fixed. The run target cannot use the network, filesystem, randomness, or the current time. Newer Function APIs add a limited fetch target that can make one HTTPS call to an external service before run executes; treat it as an exception with its own latency budget, not as a general escape hatch. Rust is more efficient for complex logic, as it provides better control over memory and results in smaller binaries and lower instruction counts; Shopify's own language guidance says the same, and any language that compiles to Wasm (Rust, Zig, TinyGo) is supported. For simpler tasks like basic field validation or simple discounts, JavaScript via the Javy runtime is often sufficient and easier for teams to maintain.

The most common cause of performance trouble is inefficient GraphQL input queries. Request only the fields you need. Requesting large objects like the entire customer history or deep product hierarchies can increase the input payload size and slow down the Function's execution. Storing pre-calculated values in cart metafields or metaobjects beats trying to calculate complex logic on the fly during the checkout process.

Next Steps for Your Engineering Team

Transitioning to Shopify Functions requires a shift in mindset from script-writing to extension development. To ensure your production environment is stable, we suggest the following actions:

Audit your existing Script Editor logic: Identify which scripts can be migrated to existing Function APIs (Discounts, Delivery, Payment, or Cart Transform).
Establish a testing standard: Implement binary testing in your CI/CD pipeline using the Shopify CLI to validate WASM artifacts before they reach production.
Centralise configuration: Move hardcoded logic into metaobjects or metafields to allow for dynamic updates without code changes.
Monitor execution logs: Regularly review the Function execution logs in the Shopify Admin to identify near-limit execution times or frequent failures.

Treat Shopify Functions as compiled software rather than scripts and you get more resilient and performant customisations that scale with the merchant's growth.

Adjacent reading: Shopify Dev Assistant in production workflows, Shopify Checkout Extensions in production, Shopify Flow beyond the basics, building subscriptions on Shopify, working around the 100 variant limit, and why most Shopify stores are slow.

Shopify Functions in Production: 2026 Patterns Guide