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 outlines the patterns we have found most effective for testing, deploying, and maintaining Functions in high-volume environments.

The Shift to Local-First Development and MCP

The developer experience for Shopify Functions has evolved significantly with the introduction of the Model Context Protocol (MCP) server for the Shopify Dev Assistant. In our experience, this represents a shift toward a more integrated local environment where developers can query documentation and API schemas directly through their IDE context. We have found that using the shopify.dev MCP server reduces the friction of looking up GraphQL schema definitions for the Input and Output objects required by Functions. This is particularly useful when working with Polaris web components or Liquid logic within the broader app context.

When building Functions, we typically see teams struggle with the initial boilerplate. 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. However, it is important to remember that while these tools speed up development, they do not replace the need for a robust local testing suite. We have found that relying solely on the Dev Assistant without a local unit testing framework leads to 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. We have found that binary testing is essential because it validates the exact artifact that will run on Shopify's infrastructure. In our experience, discrepancies can occasionally occur between the source-level logic and the compiled WASM, especially when dealing with complex memory management in Rust or the Javy runtime in JavaScript.

We typically implement a tiered testing strategy. 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. This ensures that the input transformation and the output response match the expected GraphQL schema. We have found that this approach catches 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. We typically 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 be aware of the log size limits in production environments.

Leveraging Metaobjects and Cart Metafields

A common challenge in production is making Functions dynamic without requiring a code redeploy for every configuration change. We have found that the recent support for metaobject access within Shopify Functions is a significant improvement for merchant self-service. By storing configuration data—such as tiered discount thresholds or B2B pricing rules—in metaobjects, we allow merchants to update logic via the Shopify Admin while the Function remains static.

Furthermore, the ability to access cart metafields directly within Functions and Checkout UI extensions has streamlined 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. We typically see this pattern used 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. The introduction of functionHandle has provided a more reliable way to reference specific Functions within the cart and checkout. In our experience, using handles instead of hardcoded IDs makes it easier to manage deployments across multiple environments (staging vs. production).

When deploying updates, we have found that a "blue-green" deployment strategy is often the safest approach. 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. We typically suggest that merchants 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 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. Functions cannot use the network, filesystem, randomness, or the current time, and they cannot log to STDOUT in production. We have found that Rust is generally more efficient for complex logic, as it provides better control over memory and results in smaller binaries and lower instruction counts. For simpler tasks like basic field validation or simple discounts, JavaScript via the Javy runtime is often sufficient and easier for teams to maintain.

We have found that the most common cause of performance issues is inefficient GraphQL input queries. We typically advise developers to only request the specific fields they 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. In our experience, using cart metafields or metaobjects to store pre-calculated values is often more performant than 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.

By treating Shopify Functions as compiled software rather than simple scripts, we have found that engineering teams can build 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