Website Use Policy
These are prohibited uses and operational measures to protect Cake20 and other users.
Prohibited Websites
- You cannot operate a site that violates relevant laws or provides, mediates, or promotes illegal products, information, or activities.
- It cannot be used for phishing, impersonation, distribution of malware, stealing accounts or personal information, unauthorized tracking, and sending spam.
- It may not be used to attack, compromise, or scan external systems or provide attack tools, means of circumvention, or stolen data.
- Any actions that circumvent Cake20's restrictions, access files, DB, or secrets of other websites, or harm system stability are prohibited.
- You may not post content that infringes on copyright, privacy, reputation or other third party rights.
Attacks and excessive traffic
If the website is under attack or has abnormal requests, excessive resource usage, or signs of a security breach that are likely to affect Cake20 and other users, we may apply preventive measures. In urgent cases, the operator may temporarily restrict access, posting, API, MCP or website execution without notice.
- Limit requests, block external access, stop and isolate processes
- Request to fix vulnerable features, strengthen authentication, or remove malicious content
- Suspension of use of websites where illegal or infringing activities are confirmed or where risks are not resolved
- Record retention and cooperation with relevant authorities to the extent necessary for legal obligations or security incident response
Blocking gives priority to preventing the spread of damage over punishment, and once the risk is resolved and verification is completed, restoration is reviewed.
Automatic sleep and wake up
The launched website has no HTTP requests, task or queue job activity for 5 minutes. If there are no open SSE/WebSocket connections, it sleeps internally. next HTTP/HTTPS requests are processed as is after waking up the existing release.
- Pages, static files, APIs, running tasks, and queue jobs are recognized as activities.
- It won't sleep if at least one SSE or WebSocket connection is open.
- When sleeping, the WebSocket is terminated and the memory cache and local login session are closed. It will be initialized, but PostgreSQL, Redis and files data will be maintained.
- A website that is deployed and started in operation is set to active: true in the following cron task. Automatically wakes up with internal HTTP ping 5 seconds before execution.
- Websites stopped by the user and active: false tasks are not automatically woken up.
- Sleep is an internal state of the engine and appears to the user as still running. Administrators can turn on actual status indication only when diagnostics are needed.
It does not provide users with the ability to turn snooze on or off on a per-website basis.
Automatic deletion of websites that have not been accessed for 90 days
For non-subscribed websites, 90 days have passed since the last public HTTP/HTTPS connection. After this, it will automatically be viewed as a website that is not being used or was created for testing purposes. Delete permanently. Websites that have never been accessed are from the time of creation. Counts 90 days.
- HTTP/HTTPS requests reaching the Cake20 origin, such as pages, static files, and APIs Recorded as the last connection.
- Administrator screen, editor, MCP, Task, Queue, DB/file processing and WebSocket Connection/Message does not update the last connection.
- The website of a subscribed user is not automatically deleted, regardless of the last access date.
- Automatic deletion permanently removes the source, files, builds, backups, shared database, and Redis data.
- active: A cron task that is true starts the operational website 5 seconds before execution. It wakes automatically, but does not update the last public access time.
Cake20 uses limited equipment with multiple websites, so it can last for a long time. We do not continue to store the storage space and operating resources of abandoned websites.
Operational records and verification
Website management channels to prevent misuse, analyze failures, protect accounts and enforce policies. Record traces of changes. In particular, modifying and deleting DB/cache, changing source/setting, Start, backup/restore, and time, target, status, and processing time of meaningful MCP operations The connection IP is the target.
- The request body, password, secret and MCP access key are not stored in the activity history.
- Successful simple inquiry, screen polling, preview/test, ping and MCP notification are Doesn't save.
- Changes to the website's source are stored in a separate local Git history.
- Records are checked only to the extent necessary for security investigations, failure response, and website operation.
- If policy violations or infringement circumstances are discovered, related websites and records may be preserved and access restricted.
User responsibility
- Website owners must apply authentication, permission checks, input validation, and request throttling to their public APIs.
- Secrets and AI-coded MCP addresses are not passed on to public storage, documents, or untrustworthy parties.
- If an attack or account exposure is discovered, the website is stopped, the MCP address and related secret are reissued, and the operator is notified.
- If you determine that the reason for the blocking has been resolved, you can request reconsideration by suggesting corrections and measures to prevent recurrence.