Basable

← All posts

What's new: a bucket per environment, designed frontends and faster builds

ยท Berend-Jan Lange

product changelog

The previous post covered up to 7 October. This one covers the ten days after it. Everything below is live on basable.com.

Two buckets for every environment

Apps store files: uploads, product photos, invoices, exports. A proof of concept writes them to the container’s disk, and the next deploy loses them. Every environment can now have object storage. Add one line per environment to .basable/config.yaml:

spec:
  environments:
    preview:
      objectStorage: {}
    live:
      objectStorage: {}

The environment gets two S3-compatible buckets: a private one, readable only with the environment’s own key, and a public one for what every visitor may see. The key arrives in the environment’s cluster as a secret, under the variable names the AWS SDKs read, so any S3 client works without configuration code. The assistant knows the rules: uploads, invoices and exports go in the private bucket and reach a browser through a short-lived signed link; product photos and the images of a public page go in the public one. The buckets live in the EU, on Cloudflare R2. Stored data is billed per GiB-month and requests per million, and the pricing page has the rates.

Two things ride on the buckets:

Every frontend arrives designed

The preview is the first thing you see of a new project, and until this month the assistant had no opinion about how it should look. Now every frontend is held to a design bar: a direction chosen for the product and named in the answer, a palette and typeface of its own, light and dark, real copy instead of placeholder text, every state covered (empty, loading, error), and a layout that works from 360 pixels up. A React app gets Tailwind CSS v4 and shadcn/ui components on a set of versions we installed and built ourselves. A plain HTML site gets no build step at all: files in a folder, served as they are.

One look for basable.com and the editor

The public pages and the app now share a design system: deep ink neutrals, the logo’s blue as the one brand colour, two typefaces, and a soft glow where a photo used to be. The home page has a bar you can paste into your coding agent to connect it over MCP. In the editor you can drag the dividers beside the chat to resize it, on a phone the sessions and the chat lead to the running deployment, and a dropped event stream is noticed and replaced instead of leaving the page stale.

Push to main from anywhere

A push to main from a laptop or another tool used to leave preview behind until the next Merge & Deploy merged it back. Now every push to the default branch brings dev up to date: a fast-forward when it can, a merge when it must. When the merge conflicts, the editor shows “dev behind main” with the commands to resolve it and holds Merge & Deploy until you have. Merge & Deploy itself fast-forwards whenever it can, so no merge commit appears without a reason.

Billing, said plainly

Faster builds for your own agent

Every change the assistant makes is built before it lands, by the runner in your own repository, and an agent connected over MCP from a browser builds the same way. Those builds started from an empty cache every time, which made a Rust project’s build take a quarter of an hour. They now run from the repository’s default branch and keep their caches, so each build restores the last one’s work. The cap of eight builds per session is gone too; the monthly minutes budget is the only limit. And Rust plan mode renders a whole project in one call instead of one call per nanoservice.

Smaller things

Tell us

Tuesday’s post says why the front page now reads “Made for more than a proof of concept”; most of the items above are pieces of that. If something here does not work as described, tell us at support@basable.com. That is what the alpha is for.