Shopify Static Apps, explained: serverless apps with hosting and auth handled

Most small Shopify apps are mostly boilerplate. You want to add a single admin screen that edits a metafield, or a button that triggers a bulk job, and before you write a line of the feature you are provisioning a server, wiring OAuth, validating session tokens, mounting App Bridge, and pulling in Polaris. The interesting part is small. The plumbing around it is large, and it is the part that costs you a hosting bill and a security surface forever.

Shopify's Spring '26 Edition introduced Static Apps to remove exactly that plumbing. They went generally available on June 17, 2026. This post explains what they are, the boilerplate they delete, when to reach for one over a full app, and how the related App Events API ties into the new usage-based app pricing.

What Shopify Static Apps are

Per the announcement, you can build and deploy a fully functional Shopify app without running a server. Shopify handles the hosting, App Bridge and Polaris are auto-injected, and authentication is handled by direct API access. In other words: the deliverable is your app's static frontend, and the parts that normally force you to run infrastructure are provided by the platform.

Break the four pieces apart, because each one maps to a chunk of code you no longer write:

• Hosting: Shopify serves your built assets. There is no Node process, container, or serverless function of yours to deploy, scale, or pay for.
• Authentication: handled by direct API access, so you are not writing the OAuth dance or session-token verification yourself.
• App Bridge: auto-injected, so your app is embedded in the admin (navigation, toasts, the resource picker, modals) without you bootstrapping it.
• Polaris: auto-injected, so your UI matches the rest of the admin out of the box. App Bridge makes the app work inside Shopify; Polaris makes it look like Shopify.

The piece people miss is the data layer. A Static App has no backend of yours, so where does merchant data go? Shopify's answer: Static Apps can leverage metaobjects and metafields to store relevant merchant data. Metafields attach custom values to existing resources (a product, a customer, an order). Metaobjects are your own custom data types when nothing built-in fits. Both live in the merchant's store, governed by Shopify, which is why the announcement frames this as a win for agencies: no hosting costs and no separate datastore whose security you own.

The boilerplate they remove

If you have scaffolded a traditional embedded app, you know the shape of the work before the work. A conventional admin app needs, at minimum:

• A server or serverless backend you provision, deploy, monitor, and pay for.
• The OAuth install flow plus session-token exchange and verification on every request.
• App Bridge setup and a Polaris provider wired into your frontend.
• A database, plus the migrations, backups, and access controls that come with owning merchant data.

For an app whose entire job is "show a screen, read and write some Shopify data," that stack is almost entirely overhead. Static Apps collapse it. You build the frontend; hosting, auth, App Bridge, and Polaris are handled, and your data lives in metafields and metaobjects. The work that remains is the feature, which is the part you actually wanted to build.

When to use a Static App vs a full app

The deciding question is not "how big is the app." It is where does the logic and data need to live. A Static App is the right tool when the app is a frontend over Shopify's own data and the platform can carry the rest.

Reach for a Static App when:

• The app is mainly an admin UI that reads and writes Shopify data.
• Your custom data fits in metafields and metaobjects (bulk editors, configurators, internal tools for one merchant, agency one-offs).
• You do not want to own hosting, auth, or a database, and you want the build to look native via Polaris with no setup.

Reach for a full hosted app when:

• You need a backend you control: webhook processing, scheduled jobs, or long-running tasks.
• You integrate with third-party services and hold secrets or do server-to-server calls.
• Your data does not fit Shopify's model and genuinely needs your own database.
• You need server-side logic on storefront or checkout traffic, which is often a Shopify Function rather than an app server at all.

That last point is the one developers get wrong most often. "App" is not the only place commerce logic can live. The decision spans theme, app, and Function, and picking the wrong layer is expensive to undo. We have a free lesson on exactly that call.

The App Events API and the new app pricing

Shipping without a server changes how you observe an app in production. The Spring '26 Edition pairs Static Apps with the App Events API, which accepts any event from your app that you want to track. You define an event_handle and attributes (the announcement gives examples like bulk_edit_completed, report_generated, onboarding_completed, and email_sent), and the event flows into your Dev Dashboard Logs automatically. No external analytics tool to switch into to see what your app is doing.

The events are also a billing primitive. Shopify App Pricing runs through this API: you send billable events and custom app events to one endpoint, Shopify meters them automatically, calculates charges based on the pricing model you configured, and puts them on the merchant's Shopify invoice. That is how usage-based pricing works under the new model: charge per report generated, per bulk edit completed, per email sent, and let Shopify do the metering and billing instead of building it yourself.

Where this leaves app developers

Static Apps do not replace full apps. They remove a category of app that never should have needed a server: the admin frontend over Shopify's own data. If you build small apps, internal tools, or agency one-offs, the default just changed. Start by asking whether the data fits metafields and metaobjects and whether the logic is a frontend. If both are yes, you can ship without provisioning anything, and meter usage through the App Events API on top.

The judgment that still matters is the modelling: deciding what is a metafield versus a metaobject, and which resource owns which data. Get that wrong and a serverless app is just as painful to maintain as a server-backed one. That is the durable skill, and it is the one worth learning properly.

Static Apps are one piece of a larger release. For the full developer rundown of the Spring '26 Edition, see our Spring '26 Edition for developers overview.