The app works on your screen. The distance between that and a link a stranger can open on their phone is shorter than it used to be, and it still has five places where everyone trips.
This is the article for the moment after the build. If you have not built anything yet, build your own app with AI is the one that gets you to a working preview; this one picks up from there and does not repeat it.
Every other decision depends on this one, and most people make it by accident.
A static site is a folder of files — HTML, CSS, JavaScript, images — served exactly as they are. Nothing runs on the server. The host’s job is to hand files to browsers, which is why static hosting is cheap, fast, nearly impossible to overload and almost never goes down. A calculator, a portfolio, a landing page, a documentation site, a client-side tool, a game: all static.
A server-side app runs code on every request. It needs a database, user accounts, a payment step, or anything that must stay secret. It costs more, needs monitoring, and has a far larger surface for things to go wrong.
The rule: if your app can work entirely in the browser, ship it static. You can always add a small server-side piece later for the one thing that needs it. Going the other way — simplifying a server app to static after launch — almost never happens.
For static sites this is close to a solved problem: connect a folder or a repository, get a URL. Most hosts give you a subdomain immediately and will build the site from source on every change. For server-side apps the choice is wider and more consequential, and the honest answer is that the host you already know how to operate beats the one with the better feature list.
You do not need a custom domain to share with early users; the host’s subdomain is fine and lets you launch today. Buy a domain when the app has a name you intend to keep, because changing it later means every link, bookmark and search result points somewhere old. Pointing it at the host is one DNS record, and the host’s documentation will tell you which one.
Every modern host issues and renews a certificate automatically once the domain is pointed at it. You should never be buying, uploading or renewing certificates yourself for an ordinary app. If a host asks you to, use a different host.
This is the one that causes real damage. Anything shipped to the browser is public. A key in your JavaScript is a key anyone can read in the developer tools. Secrets live in the host’s environment variables and are read only by server-side code. If your app needs a secret to work at all, that part of it cannot be static, and it should be the smallest possible server-side piece rather than the whole app.
In order of how often they happen.
The app works locally because your laptop has a file the host has never seen. Symptom: everything loads, one feature silently does nothing. Fix: list every variable the app reads and set each one on the host before the first deploy.
Your app handles /settings in JavaScript. A user refreshes on that URL and the host looks for a file called settings, finds nothing, and returns 404. Fix: tell the host to serve index.html for unknown paths. Every static host has a one-line setting for this, and every one calls it something different.
The app calls an API from a different origin and the browser blocks it. It worked locally because both were on localhost. Fix: the API has to allow your app’s origin explicitly. If the API is not yours, you need a small server-side proxy — which is the moment a static app grows its first server piece.
The page is https, one image or script is loaded over http, and the browser refuses it. Fix: search the built output for http:// and remove every instance that is not deliberate.
You deployed the fix and the user still sees the bug, because their browser or the host’s cache is holding the previous build. Fix: fingerprinted filenames for assets (most build tools do this) and a sensible cache policy on index.html. And before you tell anyone it is broken, open it in a private window.
Google’s Core Web Vitals are three numbers worth knowing even for a small app, because they describe what “feels fast” actually means. Largest Contentful Paint measures loading and should occur within 2.5 seconds. Interaction to Next Paint measures responsiveness and should be 200 milliseconds or less. Cumulative Layout Shift measures visual stability and should be 0.1 or less. They apply to all web pages and are measured at the 75th percentile of page loads, segmented across mobile and desktop.
For a small app they are less a ranking lever than a sanity check. If the largest thing on your page takes four seconds to appear on a mid-range phone on a mobile connection, that is what your users experience, whatever it looked like on your desk. Compress the images, and load the big things after the important things.
http:// and for anything that looks like a key.www to bare, or the reverse — one of them, consistently.Oppermind’s code editor gives you a live preview URL while you build, and a zero-setup static deploy when you are done — a hosted, permanent URL with no account to create anywhere else, which is the right first launch for anything that can live in the browser. Deploys to other providers use your own connected account for that provider, so the hosting relationship stays yours.
The Academy’s build live artefacts and custom tools covers the preview-to-deploy path on a real project, and the reference page has the honest line worth repeating here: a working preview is a testable artefact, not automatic production approval. Test it like a stranger would.
Free with no card, then Starter A$9.95, Pro A$29.99 and Pro Plus A$59.99 a month. Unlimited documents, spreadsheets, decks and designs on every plan.
Whatever you’re here to make, make more of it.
Static deploy gets a browser app to a public URL. It does not host your database, run your payments or manage your users, and neither does any zero-setup hosting anywhere. The moment your app needs one of those, you are choosing a server-side host, reading its documentation, and taking on the responsibility that comes with running code for other people. That is a fine thing to do. It is a different thing from what this article covers, and it is worth knowing which one you are signing up for before you click deploy.
A static site is a folder of files served as-is: HTML, CSS, JavaScript, images. Nothing runs on the server, which makes it cheap, fast and hard to break. A server-side app runs code on every request — a database, user accounts, anything that must stay secret. If your app can work entirely in the browser, static hosting is simpler and should be your default.
No. A hosted subdomain is fine for sharing with early users and for testing. Buy a domain when the app has a name you intend to keep, because changing it later means every link, bookmark and search result points at the old one. When you do, point it at the host with a DNS record and let the host issue the HTTPS certificate.
Five usual suspects: an environment variable that exists on your machine but not the host; a route that works in development but returns 404 on refresh because the host does not know it is a single-page app; a request to an API blocked by CORS; a resource loaded over http on an https page; and a cached old version. Check them in that order.
Never in the code and never in a static site. Anything shipped to the browser is public, including keys in JavaScript. Secrets live in the host’s environment variables and are only read by server-side code. If your app needs a secret to work, that part of it cannot be static.
Three metrics Google uses to measure real-user experience: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. They apply to all pages and are measured at the 75th percentile of loads. For a small app they are less a ranking lever than a sanity check that the thing feels fast on a phone.
This article is general technical information, not advice, and does not take account of your circumstances. Hosting providers, their features and their pricing change without notice; read the current documentation of whichever host you choose. You are responsible for the security, availability and legal compliance of anything you publish, including the handling of any personal data it collects. Oppermind’s zero-setup deploy is for static sites; deployments to third-party providers use your own account with that provider and are subject to its terms. Oppermind platform prices are current as at 12 September 2026, are in Australian dollars, and are subject to the plan terms at checkout.
A real code editor with live preview and zero-setup static deploy — in the same workspace as everything else you make.