Inspection and start

Separation of editor and operating environment

Database, cache memory, and storage opened from the editor use the same shared data as the production Release. Source, Debug, and Release code are separated, while data edits affect the current website immediately.

• Database: editor, review, and production use one web-{website-id} PostgreSQL DB.
• Cache memory: all execution targets share the cake20:web-{website-id}:* Redis prefix.
• Build output separates Design Preview cache, build/debug review, and build/release production output. Built browser assets live in each output's app directory; build/*/ui is not used.
• The sources are used together as one, but when the modified source becomes operational, After the user runs the final deployment.
• Review Runtime disables scheduled tasks, but data changes from APIs or manual operations remain in shared DB, Redis, and files storage.

Vite UI Preview

• When the editor opens, connect the Vite development server for each website to the internal loopback port and Run in a sandbox and the Manager relays HTTP and HMR WebSocket.
• After receiving a signal that the Cake20 View entry module and screen runtime are ready, click Preview. It displays the ready screen instead of a connection error. website The build/preview/vite cache is also reused for the next design server start.
• Saving Cake20 View/CSS only changes modules without replacing the entire production build or iframe. Renew with HMR. Restart the design server only when you change structure settings.
• The design server is reused for editor re-entry and inspection screen transitions, and Preview Shuts down after 10 minutes of no traffic.
• Images, SVG and ICO are displayed in the left script area. SVG is an image By switching scripts, you can check both the screen and source before saving. PNG, JPEG, WebP, GIF, AVIF, BMP and ICO are displayed as images.
• The WEB PREVIEW on the right changes the screen only when Cake20 View·CSS or HTML is selected. If you select any other file, it will remain on the last web screen.
• Actual viewport in the desktop/tablet/mobile menu on the right side of Web Preview You can choose your resolution. The selected screen appears with a black device frame. It is scaled proportionally within the window and maintains horizontal/vertical transitions and the last selection.
• The device and orientation in package.json are the initial selections in this menu. Settings If not, start with desktop·landscape.
• Choose index or another route from Start Page to keep that screen visible regardless of source selection. Choose None to return to the current file Preview.
• The console window is fixed below the script area, and the border can be dragged or You can adjust the height with the arrow keys.
• There is no separate design mode or runtime mode indication at the top of the editor. Control the inspection website with the start/stop button and open it in a new window on the right. Confirm.
• API and server/tasks files are checked separately by running tests for each file in the editor.
• Preview does not have a website server or sleep/wake. real endpoint We use the -test website for inspection only.
• Preview is for confirmation of modifications. The source for starting new websites and templates is the editor You can get started right away from the website list without any verification.

Edit elements directly in Preview

Preview connects the screen to Cake20 View source locations for direct static content editing. During a review run, element selection switches to the latest design Preview without stopping review, then returns to the review screen. Selection remains available during MCP work and the save rechecks the current file for conflicts.

• When you turn on element selection and press the screen, you can see the file, hash and original recorded in Cake20 View AST. Opens the element editing window based on position. Elsewhere the file comes first If anything has changed, you will be instructed to select it again in Preview instead of overwriting it.
• In Easy Mode, use the element selection to the left of the resolution. Same Cake20 View AST Page, file, tag, source without sending the location to the element editing window Delivered as a short AI Chat draft containing only offset·selector.
• Static text, properties, and public images can be changed directly from element editing. The font, size, thickness, slope, decoration, and alignment of the text are controlled by the static Tailwind class. Variables, expressions and external images that cannot be saved and directly modified are Connect with AI Chat request.
• Static phrases separated by line breaks or subtags are all entered into input fields by source location. Display. If there are multiple connected Cake20 View files, enter the hash and location of all files. After confirmation, save it as one task and undo it as well.
• The element editing window is located inside the screen without blocking the preview by dragging the title area. You can move it to any location. The last position closes the current editor screen. It stays in memory only until.
• Text and static styles are stored in the current iframe and Cake20 View component state when saved. It is maintained and immediately reflected in Vite HMR.
• AI requests simply include page, file, tag, source offset, selector, and phrase. and append dynamic expressions and image paths when necessary.
• Element editing remembers the last 100 elements. Ctrl+Z or Cmd+Z restores the original step by step, starting from the most recent task. If the file has changed in the meantime, a conflict is notified and it is not arbitrarily overwritten.
• After saving, the preview is updated only if changes are made. On current page Only the positions of the actually moved window and scroll tag are remembered and redrawn. Restores to the same position without scroll animation.

Editor review

The editor and MCP share one web-{website-id} source. Production output is stored in build/release and review output in build/debug. Built browser assets live in each output's app directory; build/*/ui is not used.

Full editor review runs build/debug at the -test URL while sharing the web-{website-id} DB, Redis, and files storage.

After preparing the review Runtime, run server/**/*.test.ts with Bun. Run. If all is successful, the inspection website will be moved to WEB PREVIEW runtime mode. You can change it and open it in a separate browser using the new window icon.

Run it with the inspection button or F9, and press it again during execution to open the test website. Stop and return to Preview your original edit without any preparation steps.

For a full review that includes the server API, you can use MCP beta_service. Scheduled tasks remain disabled, but manual changes affect shared data.

Startup and automatic deployment

Cake20 uses Git sources recorded in the currently saved source tree and operating releases. Compare trees, but always display a start button on website pages.

If there is no release or the source has changed, start with the current source as the operating release. Deploy first and then run. If there is a ready release, immediately without building Run.

A new website does not create review output first; its first review prepares build/debug. When a website has DB models, the shared DB is created by the first build that needs it.

Distribution build includes Cake20 View UI, API, route, hook, event, shared, and npm dependency. Prisma Client is created as one release. To apply a new release If it fails, revert to the previous release.

After production starts successfully, Cake20 preserves the current and previous Release. Preview reuses its latest cache, while Debug and temporary output can be cleaned up and rebuilt.

A build reads the original source directly and does not copy source into build/debug or build/release. Editor and MCP writes remain available, but changes saved during a build require a new review or release build to determine the verified result.

Run URL

Starting a website runs one web process on its assigned internal port. APIs and scheduled tasks run in the same process. Store public user files in the root files directory and Bun temporary files in the internal tmp area.

All sites share Bun binaries and install/runtime caches from TEMPLATE_ROOT/.bun; do not create a per-site tmp/bun cache.

When a release or review Runtime starts, Cake20 allocates a free port if the saved port belongs to another website or conflicts with a process. Updated release ports are also reflected in management data.

Even if the Cake20 manager is restarted, the existing website PID and web process are Maintain. Only websites that have stopped running are automatically restored, and websites that have stopped running are automatically restored. It doesn't start automatically.

The UI shows Starting for an ordinary launch, Waking only when restarting a sleeping Runtime, and Auto recovering only while the supervisor is actively restarting it.

No HTTP, Task or Queue job activity for 5 minutes and no open SSE/WebSocket connections. If not, it exits normally in the internal sleeping state. Run on user screen It is displayed as middle, and the next request quickly wakes up the existing release and delivers it.

A website deployed and started in operation runs a cron task with active: true for 5 seconds. Automatically wakes up with internal HTTP ping.

The test website run in the editor will not sleep while the editor is connected. When the last test editor is closed or the connection is lost for 2 minutes, it goes to the stopped state. Exit.

For non-subscribed websites, 90 days have passed since the last public HTTP/HTTPS connection. Afterwards, all data including source, files, shared DB, and Redis will be deleted. Automatically and permanently deleted.

Administrator can restart only the target of the website page by restarting the entire website. You can restart them one by one at 1 second intervals.

https://web-{website-id}.cake20.com

console log

• UI output is displayed together in the browser developer console and editor preview log. The test output of the selected file is displayed in the Console's Test output. For guidance on editor operations such as switching execution modes, see Preview and the running server. Output is written to the Server log.
• Test and operational builds are run in separate sandbox workers and are monitored for start, completion, and errors. It is recorded in the website log. User source build error in Cake20 It does not propagate as a system error.
• The request file path is automatically appended to the API, and the task name is automatically appended to the task.
• Use console.log in all your code without having to choose a separate Cake20 log function.

console.log("Processing begins.", data);

Source and DB automatic backup

• Each website uses an independent local Git repository and automatically commits source changes just before deployment.
• When an administrator deploys an existing website, a Git repository and first commit are automatically created as the current source.
• In release.json, the Git commit SHA used in the build is recorded to connect the release and the source.
• .cake, build, backup, files, logs, tmp and cache/creation are excluded from Git.
• Daily source backup only at 00:00 KST every day when the Git tree is different from the previous source backup. Create checkpoints. If there are no changes, a new backup will not be created.
• Automatic midnight backups are available in the editor only for current source code that has passed review or production builds. Save as ZIP in visible format. Source has changed or moved since build If the ZIP and source are the same, a new ZIP will not be created.
• If the actual DB and Prisma structure to be built are different or there are unapplied migrations, save a dump right before reflection.
• If the DB disappears during building, it will stop without automatically creating an empty DB, so you can check it first in Backup and Restore.
• At 00:00 KST every day, in cake20-core-backup outside the service folder. Create a DB backup with a name like YYYYMMDD-{Website ID}.dump. Save. If the inspected source has changed, save the .zip in the same format.
• YYYY-MM-DD-build.dump and MCP work backup before applying DB changes are for recovery purposes. Stored internally on the website separately from midnight backups.
• In Backup and Restore in the drop-down menu of Website Settings, select Source Checkpoint and Check DB dump.
• Source restoration is performed after stopping the website. Commit the current changes first, restore the files in the selected commit, and leave them as a new restored commit.
• Git restore does not change DB and files. DB from DB backup It is restored separately and does not provide automatic file restoration.
• External source ZIP and DB dump only leave the latest 2 files for each website. Cleans up older files when a new backup is created.
• Releases that exceed the retention limit and logs that have expired the retention period are also automatically cleaned up.
• Weekly latest DB backup to a temporary PostgreSQL DB or PGeasy that is different from the production DB. Actually restore and check the table and row.
• Dedicated Redis checks RDB integrity and then transfers it to temporary Redis on a separate loopback port. Start it up and check the possibility of restoration. The operational DB and Redis will not be changed.