Full workspace lane

Studio Guide

Studio is the multi-file workspace for production-grade vibe development: editable source, source-vs-runtime preview clarity, and stronger backend integration entrypoints.

Multi-file workspace guidance for serious iteration and release flows.

Implementation focus

Use Studio for modular codebases, imported projects, and any app expected to evolve across multiple releases.

Expected outcomes

Welcome to the Studio

Studio is where Vibecodr shifts from quick posting into real project building. It gives you a full editing workspace with preview, files, configuration, and publishing controls in one place so a capsule can grow without turning into a mess.

BUMP IT: update a live app

BUMP IT is the standard way to ship a new version of an app that already has a public player page. It keeps the same app identity, creates a new immutable artifact, and updates the live Drop instead of creating a second top-level listing.

What stays the same

What changes

Use BUMP IT from Studio when you are updating an existing live app. Use Publish As New App only when the work should become a deliberately separate listing with its own lineage.

Interface Overview

File Sidebar

Alt+E

Browse and manage your project files. Create, rename, delete, and organize files in folders.

Code Editor

CodeMirror 6-based editor with syntax highlighting, autocomplete, and inline errors. It understands TypeScript, JSX, JSON, and more.

Preview

Alt+P

App projects can use Source while editing and Runtime for the real built app lane. Pulse and Blueprint source stay editor-only until you publish and test the deployed Pulse endpoint.

Console

Alt+J

View console.log output from your vibe. Filter by log level (errors, warnings, info). Essential for debugging.

Config Panel

Alt+B

Manifest editor for title, description, parameters, and entry point. Configure how your vibe appears and behaves.

Hints Panel

Alt+/

Quick reference for pulse tools and code snippets. Copy examples directly into your code.

Project structure & entry resolution

During import, uploaded manifest.json files are treated as advisory source input rather than authority. Studio validates and owns the capsule manifest server-side, then uses that validated entry when it is correct. If the entry is missing, outdated, or points at the wrong file, Studio works out the most likely starting file from your project structure so you can still open and ship the project without repair work first.

The practical rule: Studio preserves editable source for you to keep working on, while publish and Runtime follow the browser-ready release entry when the imported project already includes one.

Allowed entry extensions

.html, .htm, .js, .jsx, .ts, .tsx

These are the file types Studio considers runnable starting points.

Reserved/system files

Entry resolution order

1) manifest.json entry (if the file exists)
2) package.json fields: module, browser, main, source, exports["."]
3) common filenames (in order):
   index.html, main.html, index.htm
   main.tsx, index.tsx, main.ts, index.ts, main.jsx, index.jsx, main.js, index.js
   App.tsx, App.jsx, App.js, app.tsx, app.jsx, app.js
   bundle.js
   dist/index.html, dist/main.html, build/index.html, public/index.html
   src/main.tsx, src/index.tsx, src/main.ts, src/index.ts, src/main.jsx, src/index.jsx, src/main.js, src/index.js
   src/App.tsx, src/App.jsx, src/app.tsx, src/app.jsx, src/app.ts, src/app.js

Studio surfaces these candidates in the Config panel so you can confirm the launch file instead of guessing what the runtime chose.

Image/Asset Support

Local disk paths (like C:/Users/you/image.png or /Users/you/image.png) do not exist in the browser runtime. Upload assets to your capsule and reference them by relative path.

Option A: Project assets (recommended)

  1. Upload images in Studio > Files (Creator/Pro) or Storage v2.
  2. Keep assets in folders like assets/ or src/assets/.
  3. Copy the file path or snippet from the Storage v2 file list.

Option B: External URLs (HTTPS)

Usage examples

<!-- HTML -->
<img src="assets/products/shirt.png" alt="" />

/* CSS */
.hero {
  background-image: url("assets/products/shirt.png");
}

// React
import shirtUrl from "./assets/products/shirt.png";
<img src={shirtUrl} alt="" />

Supported formats

Covers/thumbnails: PNG, JPEG, WebP, AVIF. Avatars: PNG, JPEG, WebP, GIF.

Capsule file uploads are capped at 10MB per file.

Security & CSP

Import & remix pipeline

Imports do more than copy files into Studio. Vibecodr checks what you uploaded, figures out how it should start, and warns you about anything that might surprise you later.

GitHub import

ZIP + single-file import

Remix rules

Dependency imports & runtime pipeline

Vibecodr uses one dependency system across Studio builds, imports, publish, and runtime playback. Different paths can bring different evidence into the system, like source files, lockfiles, or container-built output, but the platform still converges that evidence onto one release contract. That is how we stay permissive about project shape without letting every surface invent its own rules.

If you are importing an existing project, read Project structure & entry resolution and Import & remix pipeline first. For where the final release lives after publish, see Project Storage and Assets. For host-side trust rules, see the Published runtime code sources section in the Approved CDNs docs.

One truth plane

What publish does

Why the platform is strict here

How the dependency system works

  1. Collect evidence from the project: entry files, package metadata, lockfiles, and built output when needed.
  2. Classify imports by runtime fit: browser-safe, server-only, platform library, or blocked.
  3. Pin exact versions for publishable dependencies so the graph becomes reproducible.
  4. Mirror those exact dependencies onto Vibecodr-owned delivery paths for stable runtime reads.
  5. Generate the runtime manifest and launch contract the player uses later.
  6. Serve public reads from the fast mirror lanes whenever that is safe, with worker-backed paths still available where public direct reads are not appropriate.

Pinned npm dependency example

// package.json
{
  "dependencies": {
    "react": "18.3.1",
    "three": "0.160.0"
  }
}

import * as THREE from "three";

Library module import

import { palette } from "@alex/color-kit";

// Published libraries resolve to:
// https://vibecodr.space/lib/@alex/color-kit?v=12

If you use version ranges (like ^ or ~) without a lockfile, publish may ask you to pin exact versions before a release can freeze cleanly.

If a dependency graph needs extra packaging work, Vibecodr handles that in trusted publish-time or post-publish maintenance rather than asking public launches to do the heavy lifting.

Import rules

The Dependencies panel stores lock information for published library references and URL imports so builds stay reproducible, but the final runtime manifest is still generated by the platform.

Project Storage and Assets

Vibecodr stores project files, release output, and public asset references on platform-managed storage. The useful mental model is three lanes: editable source, published releases, and public assets. Manage files in Settings > Storage when your plan includes storage tools.

Editable source and releases

Public assets and delivery

URL behavior (Storage v2)

Storage model (human version)

Capsule storage   -> editable source + assets you keep working on
Artifact storage  -> immutable published releases used for playback
Public asset lane -> safe-to-serve mirrors for bundles, manifests, and media

Plan

Storage

Project size limit

Max files / capsule

Free

1 GB

25 MB

100

Creator

5 GB

50 MB

500

Pro

25 GB

100 MB

2000

Project size matches the ZIP upload size people see at import time. Quota cleanup and release repair happen through trusted platform maintenance. Storage analytics and object management depend on plan availability.

Keyboard Shortcuts

Shortcut

Action

Alt+S

Save current file

Alt+Enter

Publish project

Alt+E

Toggle file sidebar

Alt+P

Toggle preview panel

Alt+B

Toggle config panel

Alt+J

Toggle console panel

Alt+/

Toggle hints panel

Alt+Shift+M

Toggle problems panel

Alt+\

Toggle split editor

Alt+Shift+F

Find in files

Alt+H

Find and replace

Alt+W

Close current tab

Alt+Shift+T

Reopen closed tab

Alt+Left

Previous tab

Alt+Right

Next tab

Alt+1-9

Jump to tab by number

F8

Go to next error

Shift+F8

Go to previous error

Project Types

We spot what you're building from your files:

V

Vibe

Browser-only capsule. No server endpoints.

index.html

src/App.tsx

src/styles.css

P

Pulse

Server endpoints only. No frontend entry.

src/server/api.ts

src/server/users/[id].ts

C

Combo (Full-Stack)

One capsule with UI + endpoints.

index.html

src/App.tsx

src/server/api.ts

Workspace responsibilities

Studio is the full project workspace. It owns file editing, project structure, preview intent, import/build workflows, publish metadata, release flow, and the handoff between editable source and runnable output.

Studio must keep the source plane and runtime plane conceptually separate. Source files are what the creator edits. Runtime artifacts are the platform-built bundles that viewers execute.

  • Use Studio for modular apps, imported repositories, assets, and project-shaped work.
  • Preview from the intended runtime entry before publishing.
  • Use publish metadata to explain the app for viewers and crawlers.
  • Attach Pulses when trusted work belongs server-side.

Preview and publish discipline

A green preview is not the same as a durable release. Preview proves the current workspace can run; publishing records an immutable artifact and updates public discovery surfaces.

If a change alters runtime behavior, source access, public metadata, or backend calls, treat it as a release decision rather than a cosmetic edit.

  • Check the live runtime path, not only the editor state.
  • Use BUMP IT for the next public cut of the same app.
  • Confirm Pulse calls work through same-origin routes before telling users they are production-ready.

Example and read next

Example: you imported a Vite project with assets and a server endpoint. Use Studio to keep source files editable, preview the browser-ready output, attach the Pulse route, and publish an immutable runtime artifact.

Use these related pages when you need the next layer of guidance. They point to the most likely follow-up tasks, not every page that happens to touch the same system.

Related documentation

  • /docs/composer
  • /docs/bump-it
  • /docs/source
  • /docs/automation-safety