What is a static site (and how to host one)

When you open a page, the browser asks for a file and the server answers. The difference between a static and a dynamic site is what the server does between the request and the response. A static server just reads a file from disk and returns it. A dynamic server runs code, queries a database and builds the page on the spot.

That difference changes cost, speed, security and the kind of hosting you need. For a portfolio, blog, documentation or company page, static is usually the simplest choice.

How does a static site work under the hood?#

According to the MDN documentation, a static site's server receives a GET request, fetches the document from its file system and returns it with a 200 OK status. If the file does not exist, it answers 404. It does not change its response based on request data such as URL parameters or cookies, and it keeps no state between requests.

In practice, the site is a folder:

dist/
  index.html
  about/index.html
  assets/app.3f9c1a.js
  assets/style.82b7d0.css
  images/logo.svg

A request for /about/ becomes a read of about/index.html. A web server (such as nginx) stays online and just hands over the file. None of your code runs on the server, so there is no back-end language, database or application process of your own to maintain.

How is it different from a dynamic site?#

A dynamic site generates the response per request: who the user is, which product, what time it is. The server fetches data from a database and fills in a template.

CSS, JavaScript and images are served the same way in both. A dynamic site also has static files; what defines it is the page generated per request.

Does static mean no interactivity?#

No. "Static" is about the server, not the browser. JavaScript running in the browser can animate, filter lists, open modals and call APIs. A contact form, for example, can send its data with fetch to your own API or to a third-party service.

Many frameworks can also export a project as static files. Next.js, with output: 'export' in next.config.js, produces an out folder with HTML, CSS and JS (docs). In that mode, features that need a server do not work: Server Actions, cookies, next.config redirects and headers, Incremental Static Regeneration and dynamic routes without generateStaticParams(). Vite, with vite build, produces a dist folder (docs).

How do you build and publish a static site?#

You can write HTML and CSS by hand or use a generator (Astro, Hugo, Eleventy, Vite, Next.js and others). The flow is the same:

1. Write the content and source code.
2. Run the build, which produces the final folder (dist, out, public, depending on the tool).
3. Publish the contents of that folder to a server that serves files. That is the deploy.

With Vite, for example:

npm create vite@latest my-site -- --template vanilla --no-immediate
cd my-site
npm install
npm run build        # creates the dist/ folder
npx vite preview     # serves dist/ locally so you can check it

Before publishing, open the preview and test your links. Absolute paths like /assets/app.js break if the site is served from a subfolder; in that case set Vite's base option.

How does caching work for a static site?#

Since files only change on deploy, caching is the big speed win. MDN describes the "cache busting" pattern (Cache-Control): put a hash in the file name (app.3f9c1a.js), never modify that file and publish changes under a new name. Then you can cache it for a year:

Cache-Control: max-age=31536000, immutable

That header applies to the files under /assets/. The index.html file gets Cache-Control: no-cache, so visitors always get the latest version, which points to the new hashed files.

Generators such as Vite already put the hash in the names of assets files. You set the headers on your server or host.

When is a static site not enough?#

You need a server with code when content depends on each visitor or changes constantly and must show up immediately:

• login with sessions and per-user pages;
• shopping carts, payments and admin panels;
• pages generated from free-form search;
• real-time features, such as WebSocket chat.

A common middle ground: a static front end plus a separate API for the dynamic part. The site stays light and the API handles data and authentication. If that API grows, a load balancer can spread the load.

Which terms show up next to "static site"?#

• SSG (static site generation): generating HTML at build time instead of on each request.
• SPA: a single-page application that loads JavaScript and builds screens in the browser; it can be served as static files.
• Jamstack: an industry name for static sites that use APIs for whatever is dynamic.
• CDN: a network that keeps copies of your files in many places, close to visitors.

To get HTTPS and your own address you need a certificate (how Let's Encrypt works) and a DNS record (how to point a domain).

How to do this on Square Cloud#

A static site only needs a web server that stays online and serves the build folder. On Square Cloud, among several runtimes such as Node.js, Python and Go, there is one for static sites: nginx is always running and serving your files, and none of your code runs on the server. You upload the folder (dist, out) as a ZIP in the dashboard, with the CLI, from GitHub or with the VS Code extension. The squarecloud.app file is optional: the dashboard generates it on deploy, or you write it at the project root. See the runtimes available today on Runtimes.

Updating the site means replacing files. A new commit, an upload or an edit in the file manager goes live right away, with no rebuild or restart. For a SPA, rename the build's index.html to vite.html: the runtime answers every path that isn't a file with it, and without it unknown paths get your 404.html.

With none of your code to run, the site usually fits in the minimum for a web application, 512 MB of your plan's RAM. Hobby, from R$12.49 per month, already covers sites and comes with a *.squareweb.app subdomain with HTTPS, a global CDN and unlimited traffic (fair-use policy). A custom domain starts on Standard: you create the DNS records shown in the dashboard at your registrar, and TLS is automatic. Start with the static sites runtime.