Free static sites, with no cluster and no build step
A lot of projects start as a page: a landing page for an idea, a portfolio, the docs for a library, a restaurant’s menu. Until October every Basable environment was a Kubernetes cluster of its own, which is a lot of machinery for files that do not change between one visitor and the next. So an environment can now be static: it runs nothing at all, and its files are served straight from its storage bucket.
What static means
A static environment has no container, no Kubernetes, nothing to size and
nothing that goes to sleep. The project’s .basable/config.yaml says so with
static: {} where the CPU and memory would otherwise be:
apiVersion: basable.com/v1
kind: TenantConfig
spec:
environments:
preview:
static: {}
live:
static: {}
Everything else about the project stays the same: a preview environment on the
dev branch, a live one on main, an address for each, and your own
domains on top, over HTTPS.
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. That is
all. There is no workflow and no CI run: when you push, Basable takes site/
from the commit itself, and the site is live within seconds. A repository
without a single workflow file deploys. This is how the assistant builds a
plain site, and you can do the same by hand.
From a build
A site with a build step, a React app or the output of a site generator, is
built by your repository’s own CI workflow, which uploads the output directory
as an artifact named static. The environment says it takes its site from
there:
spec:
environments:
preview:
static:
source: artifact
Basable waits for the run, downloads the artifact and serves it.
How it serves
- 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 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 switches only once every file of the new one is in place. A visitor never sees half a deploy.
What it costs
Nothing, as long as the site stays inside the monthly allowance every environment gets for good: 1 GiB stored, a million reads and a hundred thousand writes. Every file served to a browser is one read, so a million reads is, say, a page of ten files opened a hundred thousand times a month. Inside that, a site needs no payment method, however long it runs, and a project that is only a static site is never deleted for lack of one.
Above the allowance the usual rates apply when a payment method is on file: €0.03 per GiB stored per month and €0.72 per million reads, excluding VAT. 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. Nothing is deleted.
Limits, on purpose
A site is at most 64 MiB and 5,000 files per deploy (16 MiB zipped, for a build artifact). Video and large images belong in the environment’s bucket, linked from the page, not in the site itself. A site that needs more than files, such as redirects, a proxy or a login, is a container instead, and the assistant can set one up.
What is not there yet
The shape an environment is created with stays for now: a static environment cannot become one with a cluster, nor the other way round. If you expect the site to grow a backend soon, start with an ordinary environment and let its frontend be served from the bucket beside the app; that is already the default for a frontend that is only files. Switching in place is planned.
Describe a site to the assistant, or push a site/ directory of your own.
Sign up with just your email; a static site needs no payment
method.