One chat.
One branch. One feature.
Vibe Coding replaces the traditional developer workflow — IDE, local environment, GitHub PRs, manual deploys — with a single chat interface that controls everything. Every conversation is a git branch. Every app change is tracked, reviewable, and reversible.
Your Environment
Everyone gets their own container. It's your server, running your apps.
A Vibe Coding container is a self-contained server environment — your own Docker instance running all your apps, your own Supabase database, and a dedicated URL. It can live on the Bit Creative server or on your own infrastructure.
Hosted on Bit Creative
Up and running in minutes. We manage the server, backups, and uptime. Your apps are at vibeXXX.bitcreative.com.au.
Hosted on your infrastructure
We deploy to your server or cloud account. You own the hardware, the data, and the bill. Same platform, your domain.
Single login
The same account and password works across your AI chat and your Vibe Coding container. No separate credentials to manage.
Authentication enforced at URL level
All apps are private by default. Navigating directly to an app URL without being logged in doesn't show the app — it redirects to login.
Password reset — two options
Containers support both Supabase-native auth and email-token reset flows, so the authentication layer works regardless of how the database is configured.
The Launcher
Your apps, one screen.
Icon & colour per app
Every app has a Lucide icon and an accent colour. They show in the launcher, the top navigation bar, and the app switcher widget. Pick them yourself or hit Suggest and the AI chooses based on the app name and description.
Recently used at the top
The apps you've opened most recently float to the top of the launcher. Alphabetical order applies below that. No pinning needed — usage pattern drives the layout.
App types
Full apps (with a UI), Automations (background cron tasks), Webhooks (incoming HTTP endpoints), and Links (external URL bookmarks). All managed from the same launcher and App Management screen.
Permissions enforced in the launcher
If a user doesn't have permission to see an app, it doesn't appear in their launcher. The app is invisible, not just locked.
The Development Interface
No IDE. No local setup. Just chat.
Each new chat session automatically creates a git worktree on the server — an isolated copy of the codebase with its own branch. The AI edits files in that branch. Multiple people can be coding different features at the same time, in separate chats, without touching each other's work.
Isolation by default
Each chat has its own branch. Two people working on two features at the same time see none of each other's in-progress changes. Merge happens explicitly when the work is done.
The conversation is the record
Why a change was made lives in the chat that made it. No PR description to write, no commit message to craft. Open the chat, read the thread.
Inline diff in AI messages
When the AI modifies code, the change is shown as a diff inline in the message — what was removed and what was added. You see exactly what changed before it's committed.
Visual Check
After a code change, the AI can trigger a Visual Check — it calls the browser automation tool, loads the affected page, and takes a screenshot. You see the result without leaving the chat.
HMR — changes are live immediately
The app runs with Hot Module Replacement. When the AI saves a file, the browser updates without a full reload. The change is visible in under a second.
Resume any time
Close the chat and reopen it tomorrow. The worktree is where you left it. Incomplete work doesn't disappear.
Coding indicators in the chat input bar
App tag
Which app this chat is editing. Shown as a coloured badge in the sidebar chat list.
DB pill
The current target database (staging or live). Tap to switch. Resets to staging after every AI turn — so the model can't accidentally stay on live.
Chat status
Whether this chat is Open, ready for Review, or Approved.
Migration badge
A warning when database changes made in this chat may still need to be applied to the other database. Disappears once both are in sync.
Chat Status
A simple status for every chat.
There is active work in the chat, or the result has not yet been marked as ready for review.
The assistant has finished its work and the chat is waiting for a human to check the result.
A human has checked the result and marked the chat as done.
The same dot appears in the sidebar
Every chat in the sidebar can show a status dot next to its title. This is a general status view because all assistants can have open, review, and approved chats.
Status means human workflow
Open, Review, and Approved describe where the conversation is in the human review process. They do not describe whether code has been pushed, deployed, or copied between environments.
Technical Indicators
Git, deploy, and migration indicators are separate from chat status.
Vibe Coding chats can also show technical state for developers and operators. These indicators are useful when shipping code or coordinating database changes, but they are deliberately kept separate from the simple Open, Review, and Approved chat status.
Git transport state
Vibe Coder chats can expose whether the code branch is open, merged, pushed, or deployed. That describes where the files are, not whether a human has approved the work.
Migration reminders
A yellow migration badge in the chat input, or a yellow dot in the sidebar, means that database changes from that chat may still need to be considered for the matching database.
Git is transport, approval is intent
A chat can be pushed to GitHub and still be in Review if the user has not accepted the work yet. The reverse can also be true in deployment workflows: a user can approve a chat before a deploy job has copied files to every target. Keeping the two states separate avoids treating "the files moved" as the same thing as "the work is done".
Deployment Model
Two modes. One decision.
Vibe-coded
Open → Review → Approved
One environment. Changes go live the moment they're merged. The git state moves through merged and pushed, while the chat itself moves from Open to Review when the AI finishes, then to Approved when the user is done with it.
Best for: internal tools, prototypes, fast iteration by non-developers.
Dual-repository
Review → Approved, then deploy
Two environments — staging and live. Code goes to staging first. A human reviews the staging site, marks the chat Approved, then deploys to live as an explicit act. Deployed is a transport state, shown separately from the human approval state.
Best for: production websites, customer-facing apps, anything where a bad deploy has consequences.
Same chat engine. Different shipping policy.
Both modes use identical worktrees, git workflow, and chat interface. Some clients deploy the whole lot in one rsync-style release. Others deploy one approved chat at a time. The chat approval status stays consistent across both policies.
Shipping Code
The Deploy App — deployments grouped by chat.
Instead of a list of commits or pull requests, the deploy view groups pending changes by the chat that produced them. Each entry is a chat: title, author, status dot, AI-generated summary of what changed, and a full diff of every file touched.
Ship everything that's been merged into staging in one action. Files changed across all chats are shown in a diff panel on the right.
Cherry-pick a single feature to live without shipping everything else that's pending.
The full file-level diff between staging and live is visible before you deploy. A (added), M (modified), D (deleted) per file.
Pushing code to the live server places files on disk but doesn't swap out the running app. The Restart Container button does the swap. Until then, customers see the previous version — that gap is your smoke-test window.
Any chat with database changes that may still need to be mirrored to the matching database shows a migration badge. The deploy view surfaces these so they don't get missed.
Architecture
Why there are two databases.
For dual-repository apps, there's a staging database and a live database. The live database is what your website talks to. The staging database has a read-only mirror of all that data, plus your internal app tables — so your tools can query live customer data without connecting to the live database directly.
Live DB
Your website's data
Orders, customers, products — whatever your live site writes. The website always talks directly to this database. The AI can read and write here when the DB pill is switched to Live.
Staging DB
Replica + internal tables
A continuously-synced mirror of the live data (read-only), plus your internal app tables (writeable). The AI defaults to staging — it can read live data here without touching the live database.
Staging first. Deploy the code, then apply the migration to live.
Staging only. Your app tables live there permanently.
Flip the DB pill to Live. The AI writes directly. Pill resets on the next turn.
Read-only. The router blocks writes — the next replication tick would overwrite them anyway.
Database Migration Reminders
Migrations are reminders, not errors.
Some apps have two connected databases: staging, the default database used while building or testing, and live, the production database used by the real app. When a change is made to one database, the system may need to remember that the same change still needs to be made to the other database. That reminder is stored as a migration row.
A migration row does not mean something has gone wrong. It means: this change has been made on one database, but the matching database may still need the same change.
If a change is made on staging
The system checks whether the same change was already made on live.
- If live already has the same change, the reminder is cleared.
- If live does not have the same change, a migration reminder is created.
If a change is made on live
The system checks whether the same change was already made on staging.
- If staging already has the same change, the reminder is cleared.
- If staging does not have the same change, a migration reminder is created.
Migrations work in both directions
They are not only "staging to live". They are a reminder that the two databases are currently out of sync for a specific change.
When a reminder is cleared
Staging first
- A column is added on staging.
- A migration reminder is created.
- The same column is later added on live.
- The reminder is deleted because both databases now match.
Live first
- A column is added on live.
- A migration reminder is created.
- The same column is later added on staging.
- The reminder is deleted because both databases now match.
What counts as the same change
The system only treats two changes as matching when the important details are the same. This avoids accidentally clearing the wrong reminder.
Special case: replicated data
Some tables copy data automatically from live back to staging. For these tables, a normal data change on live does not need a migration reminder, because the data will automatically flow back to staging.
Example: a row is added on live, the table is replicated, staging receives the row automatically, and no migration reminder is needed.
This only applies to data. Schema changes, such as adding a new column, do not replicate automatically. If a column is added on live, staging still needs that column added manually, so a migration reminder is still needed unless staging already has the matching change.
Simple mental model
If only one database has the change, keep a reminder.
If both databases have the change, remove the reminder.
If live data will automatically replicate to staging, no reminder is needed for that data change.
Schema changes always need to be checked on both databases.
Security Architecture
The model never actually touches anything directly.
Every action the AI takes — editing a file, running a query, calling an API — goes through a gated handler. The handler validates the request, enforces permissions, and decides whether to execute it. "The model can do X" is shorthand for "the system does X on the model's request, if the gates allow."
modify_code_files_vibeAll file writes go through a handler that validates the path is inside the chat's worktree. Paths outside the worktree are rejected. The AI cannot edit the base repo, other app directories, or system files.
supabase-routerEvery SQL call goes through a proxy that enforces per-table, per-organisation permissions, routes to the correct database (staging vs live), and logs the mutation for the migration tracker.
supabase_utilitiesCreating tables, adding columns, modifying indexes — all go through a dedicated utility that registers changes in the platform's table registry (crm_tabs), so AI context stays current.
Not accessibleThe .env file is not exposed to the AI. Secrets are stored outside the worktree. The model can use credentials stored in the Credentials app via controlled function calls — it can never read the raw secret values.
Pre-commit checkFile changes are validated for syntax errors before they're committed. A Svelte file with broken syntax fails validation and rolls back — the working version stays intact.
Git worktreeBecause every chat is a git branch, any change can be reverted. Open another chat, describe what to revert, and the AI reads the git history and undoes it.
This is not AI-assisted coding with a safety label slapped on it. The constraints are architectural — the model is structurally unable to reach things it shouldn't reach, not just instructed not to.
Every gate is configurable. Permissions can be tightened or loosened per table, per organisation, per environment. The defaults are conservative. You loosen them deliberately, not by accident.
Background Automations
Three automations keep the system self-maintaining.
Vibe Coding isn't just a chat interface — it runs a set of background automations that continuously improve code quality, keep deployments live, and give AI models better context. These run without any human intervention.
Code Intelligence
Runs daily — one app per run
The platform reviews its own code. Each run selects one app that has changed since the last review, launches an AI session against it, and produces a structured analysis. Over time, every app gets reviewed.
SHA-based change detection
Compares current git HEAD to the SHA from the last review. Only apps with changed .svelte, .js, or .ts files are eligible. First-time apps are always eligible.
@CONTEXT documentation blocks
The AI reads every changed file and writes or updates @CONTEXT-LEAN and @CONTEXT-DETAILED comment blocks. These blocks are what future AI sessions read to understand what a file does — without needing to read the full code.
App description update
The app's description in the launcher and app switcher is updated to reflect what the app actually does now, not what it did when it was first created.
Structured findings log
Bugs, recommendations, and open questions are written to a findings table. The next review session reads existing findings to avoid duplicates — it builds on prior analysis rather than starting over.
Template port
If an app is flagged as a template source, reusable improvements — UI patterns, utility functions, architecture decisions — are ported to the shared template repository. Every new client container inherits the improvement.
Git push → live in seconds
Triggered on every push to main
A webhook fires every time code is pushed to the main branch on GitHub. The server pulls the latest commit automatically. There's no deploy step, no build pipeline to babysit, no manual restart.
This means you can use any editor — claude.ai/code, VS Code, Cursor, or a plain terminal — push via git as you normally would, and the change is live. Vibe Coding's chat interface is one path in. Git is another. They both end up in the same place.
Hourly table data snapshot
Runs every hour
Every hour, the platform samples real rows from every registered database table and writes the results as Markdown files directly into the repository — one file per table, plus a file containing all database function definitions.
Why this matters for AI context
Schema alone tells an AI what columns exist. Sample data tells it what the data actually looks like — the real shape of a customer record, a task, an email. The difference in context quality is significant. AI sessions that can read "here are five real rows from this table" produce far more accurate queries and transformations than sessions that can only read column names and types.