What Basable is, and what it is not
Most “describe your app and we’ll build it” tools stop at the demo. You get a
preview, it looks right, and then you find out that making it real means
exporting a zip file and setting up everything yourself.
Basable is built the other way round. The description produces a real
application, and that application is deployed the same way it will run in
production: a container image built by your own CI, applied to an isolated
environment with its own hostname and TLS.
The three things that matter
Your code is yours. Everything the assistant writes lands in a git
repository you own, on your own git host. There is no proprietary format and no
export step, because there is nothing to export from. Clone it, edit it by hand,
push, and the platform deploys what you pushed.
Two environments, one repository. Work goes to the dev branch and deploys
to a preview environment you can share. Merging to main deploys the live one.
Previews sleep after thirty minutes of inactivity and wake on the next push, so
an idle preview costs nothing.
Isolation is real. Every project runs in its own sandboxed environment, with
its own resource quota and network policy, on a kernel-isolated runtime. Your
application cannot see anyone else’s, and nobody else’s can see yours.
What is still rough
The platform is in alpha, and the honest summary is that the deployment pipeline
is further along than the polish around it. Expect the occasional failed deploy
that needs a retry, and error messages written for someone who already knows how
Kubernetes works.
We do not yet charge for anything beyond the free tier during alpha, and the
terms say plainly that we accept no liability for what happens to a
deployed site while that is true. Keep backups of anything you care about. Since
the code is in your own repository, that is usually a matter of having cloned it
once.
Where to start
How it works walks through the flow end to end, and
pricing has the actual numbers rather than a “contact us” button.