Static sites and App Hosting: what each actually runs, and how to choose

One dashboard, and a single difference that decides everything else: what executes when a visitor asks for a page.

The one-line difference

A static site serves files that already exist. App Hosting runs code at request time and produces the response on the spot.

Every other distinction follows from that. A static page is the same bytes for every visitor until you publish again. An app page is assembled after the request arrives, which is why it can read a database, know who is signed in, and remember a cart.

What a static site runs

Built HTML, CSS, JavaScript and images — dropped in as a folder, pushed to Git, or generated by the engine. Nothing of ours executes per request: no PHP, no Node, no database.

It is metered by page count, not by traffic — see also: the static tier limits. One page is free forever; Start and Build raise the page allowance; Studio removes it. Requests are not metered on any static tier, so a page that gets linked from somewhere busy costs you nothing extra.

What static cannot do is structural, and no amount of configuration changes it: it cannot accept a form and store the result, it cannot tell two visitors apart, and it cannot show anything that depends on who is asking. Those things can be bolted on with third-party services, and plenty of brochure sites should — but the thing doing that work is then somebody else's product, and you are their customer too.

What App Hosting runs

Managed hosting for what the engine builds: static files, dynamic sites, or an application you bring yourself. It executes per request, it can write to a database, and it therefore needs care — updates, backups, plugin maintenance.

It is metered by number of apps and monthly visits, with no page cap. Plans run Hobby, Pro and Enterprise.

Be clear about what you are taking on: something is running that can fall out of date. Automatic core and plugin updates tested on staging first, daily backups, and malware scans exist on this product because they have to, not because they look good in a feature list. A site that never needed a patch is not the site you are describing.

Choosing: the table that decides it

When to pay for App Hosting anyway

Choose App Hosting even though it costs more when the site has to accept input, when the people editing it will only work inside a familiar admin, when you are migrating an existing WordPress install, or when a plugin does something central to the business. In each of those cases static is not the cheaper option — it is the wrong shape, and the workaround will cost more than the plan.

The free first year on App Hosting belongs in this paragraph with all of its conditions attached, because it is not a price: it is available by invitation, it requires a domain registered with Zeso, and from month thirteen it renews at the published Pro rate, which is shown to you before you claim rather than on the first invoice. It is a bounded offer. Nothing about App Hosting is free forever; the only thing that is free forever is the one-page static tier.

When static is the wrong choice

Static is wrong the moment a page's contents depend on the request rather than on the publish: search results, filtered listings, a customer dashboard, a booking form, anything personalised. It is also wrong if nobody on your side will ever run a build — the engine and the visual editor both publish for you, which is the case static was designed around.

Moving between them

Going from static to App Hosting is a one-click move in the dashboard: same domain, same dashboard, no migration, no re-deploys. Going back is not a toggle. An app becomes a static site when its pages are generated into files and published as a static project — work you do deliberately, not a switch you flip, and the reason to decide this before you build rather than after.