Static vs App Hosting: what each actually runs, and how to choose
One difference decides everything: whether anything executes when a visitor asks for a page. What that implies for cost, maintenance, and the shape of your site.
Static vs App Hosting: what each actually runs
Two products, one dashboard, and a single difference that decides everything else: what executes when a visitor asks for a page.
The one-line difference
Static Hosting 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 Static Hosting 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: static hosting limits. One page is free forever; Starter and Pro raise the page allowance; Enterprise 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
A managed container with a runtime in it: WordPress, ZESO-CMS, or a Node or PHP 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 Launch, Grow, Scale 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
| If your site needs… | Choose | Because |
|---|---|---|
| A single landing page | Static, Free | One page is free forever, and there is nothing to maintain. |
| A handful of brochure pages | Static, Starter or Pro | Metered by pages; no runtime to patch. |
| A blog you publish to weekly | Static — or App with ZESO-CMS | Collection rows and publish work well statically; choose App if you want an admin UI and comments. |
| WordPress, with plugins and a theme you already own | App Hosting | PHP and a database are not optional there. |
| Accounts, login, or member-only pages | App Hosting | Static pages cannot tell visitors apart. |
| A cart, checkout, or anything that stores orders | App Hosting | State has to live somewhere that runs code. |
| Traffic-heavy content that rarely changes | Static Hosting | The response is already built; nothing runs per request. |
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 both of its conditions attached, because it is not a price: it requires a domain registered with Zeso, and from month thirteen it renews at the published Launch 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.