Static sites

A site that is only files, with no server behind it, needs no container and no cluster. Basable serves it straight from the environment's storage, on the same addresses and custom domains every project gets, and it costs no compute.

A static environment is one that runs nothing: no container, no Kubernetes, nothing to size and nothing that sleeps. Your project's .basable/config.yaml says so with static: {} in place of the usual sizing. Everything else about the project is the same: a preview environment on the dev branch, a live one on main, a hostname for each, and your own domains on top.

Two ways to get the files there

1. From the repository, in seconds

For a plain site: HTML, CSS, JavaScript and images that need no build step. Put the files in a site/ directory, with index.html at its root, and declare the environment static:

apiVersion: basable.com/v1
kind: TenantConfig
spec:
  environments:
    preview:
      static: {}
    live:
      static: {}

That is all. There is no workflow and no CI run: when you push, Basable takes the site/ directory from the commit itself and the site is live within seconds. A repository with no workflow file at all deploys. The AI assistant builds plain sites this way, and so can you by hand.

2. From a build

For a site with a build step, such as a React app or a site generator. Your repository's build.yaml workflow builds the site and uploads the output directory as an artifact named static, and the environment says it takes the site from there:

spec:
  environments:
    preview:
      static:
        source: artifact

Basable waits for the run, downloads the artifact and serves it. The artifact holds the built directory's files themselves, so index.html is at the top of it.

What serving looks like

The site answers on the environment's address and on every custom domain you add, over HTTPS.
A directory's path, with or without the trailing slash, answers that directory's index.html, so a multi-page site links its pages the way any web server serves them.
A path that names no file answers the site's root index.html, so a single-page app's own routes load.
Each deploy keeps the previous commit's site beside the new one, and the switch happens only once every file of the new one is in place.

Limits

A site is at most 64 MiB and 5,000 files per deploy (16 MiB zipped, for a build artifact). Large media belongs in the environment's storage bucket, linked from the page, not in the site itself. A site that needs more than this, or server-side behaviour such as redirects, proxying or authentication, is a container instead: the assistant can set one up, and the environment is sized like any other.

What it costs

A static environment reserves no compute, so it is billed only for what its buckets store and serve, and every environment gets a free allowance of that every month, for good: 1 GiB stored, 1,000,000 requests (Reads (class B requests)) and 100,000 requests (Writes and lists (class A requests)). A site inside that costs nothing and needs no payment method, however long it runs. Above it the usual rates apply when a payment method is on file. Without one, a site that passes its monthly request allowance answers "Site paused" for the rest of the month, and serves again when the month turns or a payment method is added. The payment deadline that deletes an organisation's projects applies to projects that run a cluster; a project that is only a static site is kept.

Growing a backend later

The shape an environment was created with stays for now: a static environment cannot become one with a cluster, nor the other way round. A site you expect to grow a backend soon starts as an ordinary sized environment with its frontend served from the bucket beside the app; a static site that later needs a server becomes a new project. Switching in place is planned.