Skip to content
Butterbase
Changelog

Templates

A template is a public Butterbase app that anyone can clone. Cloning gives you a brand-new app you own outright — schema, security policies, functions, Durable Objects, and source files already in place, running on a live backend in the region you pick.

This is not a starter repo. There is no “now wire up your database” step. The clone comes up provisioned, migrated, and deployable.

Two first-party templates are published today — a full AI-native CRM and an AI support desk. See Available Templates.

Why start from a template

Section titled “Why start from a template”

You skip the boring 80%. Auth wiring, table design, RLS policies, function scaffolding, storage buckets, CORS — the parts every app needs and nobody enjoys writing — arrive already done and already working together.

You start from something that ran. A template isn’t a snapshot of someone’s aspirations. It’s a copy of an app that was actually deployed, with the schema that actually served traffic.

You own it completely. The clone is your app, in your organization, on your plan, in your region. There is no upstream dependency, no license check, no phone-home. The publisher can delete their app tomorrow and yours keeps running.

Nothing of the publisher’s leaks to you, and nothing of yours leaks to them. Secrets are the hard line: API keys, OAuth client secrets, and BYOK credentials never cross. You see the names of the environment variables a template needs so you know exactly what to fill in — never the values.

The tedious bits get filled in for you. Butterbase resolves BUTTERBASE_API_URL and BUTTERBASE_APP_ID to your new app automatically, and can mint a fresh scoped API key for BUTTERBASE_API_KEY so the cloned functions can talk to their own backend on the first invocation.

You know what you’re signing up for before you clone. A preflight call lists every environment variable the template’s functions and Durable Objects expect, and marks each one as auto-filled or “you must supply this.”

It works from wherever you work. The dashboard, the CLI, the REST API, and any MCP-connected AI agent all drive the same clone pipeline.

What you get in a clone

Section titled “What you get in a clone”
CopiedNot copied
Database schema — tables, columns, indexesEnd-user accounts and sessions
Row-level security policiesOAuth client secrets
Serverless function codeFunction environment variable values
Durable Object classesBYOK AI provider keys
Repo files (latest pushed snapshot)Custom domains
The published frontend, re-pointed at your app—
Non-secret config — storage settings, CORS, OAuth providers and redirect URLs, AI model defaultsBilling and Stripe Connect setup
App-level environment variablesInvocation history and audit logs
Rows in tables the publisher marked _seed: trueInvocation history and audit logs

Full detail in Configuring Your Clone.

How a clone runs

Section titled “How a clone runs”

Cloning is asynchronous. You get a job_id back immediately and poll it. The job walks these stages, so a status read tells you exactly where it is:

pending → processing → replaying_schema → replaying_rls → replaying_durable_objects → replaying_functions → replaying_config → copying_repo → seeding_data → completed

A failed job reports error_message and can be retried. A successful job can still return warnings[] — soft failures worth reading, like an auth hook that couldn’t be rebound.

Limits

Section titled “Limits”
LimitValue
Clones started per user5 per hour
Concurrent in-flight clones per user3
Source requirementsvisibility: public and at least one butterbase repo push
QuotaEach clone is a new app and counts against your plan’s project limit
Name uniquenessApp names are globally unique — a taken name returns 409

Where to go next

Section titled “Where to go next”