Drive

Documentation Index

Fetch the complete documentation index at: https://mulerun.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

​

Overview

MuleRun Drive is the cloud file space built into the MuleRun platform. It lets users (or the super agent acting on their behalf) gather everything into a single directory tree—files produced during tasks, reference materials for the agent, and personal documents kept long-term—and manage them either directly from the entry on the left side of chat, or via the agent in conversation. Drive offers two entry points:

• The “Drive” entry in MuleRun Chat’s left navigation: Pinned by default in the sidebar’s tools area. Once opened, it lists all files and subfolders in the current directory in a table view, along with a search box, an upload button, a new-folder button, and the account’s current storage usage.
• Read/write by the super agent during chat: Users can attach Drive files to messages so the agent can read them; files newly generated by the agent during task execution automatically land in the Agent Workspace directory, viewable by going back to the Drive entry.

Drive’s capabilities include:

• Browse all files and folders under the account, sorted by modified time (newest first) by default—click column headers to toggle ascending/descending—with instant filename search within the current directory.
• Upload local files of any type (large files are automatically split into multiple chunks for upload), or create empty folders to organize materials.
• Online preview of common formats: images, video, audio, PDF, Markdown, code, CSV, HTML, and Word / Excel / PowerPoint (Office documents support online editing and auto-save back to Drive).
• Download individual files to local.
• Rename and delete files or folders.
• Click “From Drive” in the chat input box to attach an existing Drive file directly to the current message and send it to the agent.

​

Target Users

• Individual users — Applicable. One-off publishing of portfolios, event sign-up forms, small tools, or AI app demos; no need to buy domains, configure servers, or apply for SSL certificates.
• Team members — Applicable. Publish internal or external pages under the team subscription; each member has their own Pages quota and they don’t compete.
• Team admins — Partially applicable. Purchase a higher tier in the subscription center for the team. Each page is currently managed by its creator individually—Pages does not yet offer a team-aggregated panel of all members’ pages.

​

Use Cases

• AI mini-apps built by the agent — Describe the need in chat; the agent prepares the content, creates a dynamic page via Pages, and returns an accessible link.
• Temporary event landing pages — The agent creates and publishes a static page; you get a mule.page link to share within seconds. Delete from the card menu when the event ends.
• Collecting and storing form data — The agent creates a dynamic page with a database; visitor submissions are saved automatically. The agent can also help you view table names and contents.
• Bind a custom domain — From a card’s menu, click “Custom Domain”, enter the domain, and follow the DNS prompts. The platform issues a certificate and takes over traffic automatically.
• Invite-only beta pages — Enable “Access Code” from the card menu; visitors without the code can’t see the content. Once a visitor passes, they usually skip re-entry for a while.
• One-click rollback if a release goes wrong — Have the agent publish a new version; if something breaks, switch back to the previous version with one click.

​

Quick Start

Shortest path: publish a static page via the super agent in chat.   1. Describe the need in MuleRun chat, e.g., “Make me a personal resume page.”   2. The agent prepares the content and shows a preview in chat.   3. Confirm and click Publish; the agent creates a Pages site automatically.   4. The platform assigns a default domain (e.g., a1b2c3d4.mule.page) and completes deployment.   5. A card with the accessible link appears in chat.   6. Click the link to open the page; the new site also shows up under the “Pages” entry in the left navigation for management. When done, you should see a “Site published” card in chat. If it stays stuck in “deploying”, see the FAQs below.

​

Detailed Guide

​

Creating a Page

Pages supports two types of sites:

• Static — Best for pure front-end content: personal sites, portfolios, marketing pages, doc sites, single-page apps. More consistent load times.
• Dynamic — Best when you need forms, data storage, or calls to other services. Currently only Node.js backends are supported; the agent generates Node.js code accordingly. More backend languages will be added over time.

The site type is fixed at creation and cannot be switched in-place—changing type requires creating a new site. How it works:   1. Tell the agent in chat what type of site to create (static or dynamic), and whether a dynamic site should also have a database attached. If the account is already at its page-count limit, you’ll be prompted to upgrade.   2. The platform assigns a *.mule.page default domain and creates the site. The new site appears in the chat preview pane and also in the Pages entry.   3. If a database was requested, the platform begins provisioning a dedicated one. The site can’t be published until the database is ready; the agent will retry shortly. Constraints:

• When renaming on the Pages page, names allow only lowercase letters, digits, and hyphens (-), up to 30 characters.
• A freshly created site is not yet accessible—it goes live only after the agent’s first publish.

Publishing New Versions and Rolling Back Each publish produces a new version, and prior versions are retained so you can switch back at any time. New publish. Tell the agent your changes in chat to trigger a new publish. When done, the card’s status flips from “Deploying” to “Published”; visitors don’t drop during the switch, and the first request right after may be slightly slower. If a publish fails (e.g., bad agent output), the card shows “Failed”—ask the agent to fix and republish. Roll back. In the Pages entry, open a card’s menu, click “Switch Version”, pick a historical version, and submit. No republish needed. Constraint: A site serves only one version publicly at a time. Other versions remain available for switching. Custom Domain Pages assigns each site a *.mule.page default domain. Paid users can also bind a custom domain (e.g., www.mybrand.com); the platform handles certificates and CDN automatically. How it works:   1. From a card’s menu in Pages, click “Custom Domain” and enter the domain you want to bind.   2. The second step of the dialog shows the CNAME record to add at your DNS provider (Type / Name / Value, with Proxy set to Disabled). Copy and configure as instructed. The platform begins issuing the certificate and verifying the binding.   3. Once DNS resolution and platform verification both complete, visitors can reach the site via the new domain, and the card’s link shows the custom domain. Constraints:

• Only one custom domain per site—personal-tier multi-domain binding is not supported. The Pages page currently supports first-time binding only; there’s no entry to unbind or change a custom domain afterward. 
• The custom and default domains point to the same site and share the same access code and quota.
• Right after submission, the card immediately shows the custom domain, but actual reachability depends on DNS and platform verification—there may be a several-minute window where the link is shown but not yet accessible.

Access Code Protection With an access code set, visitors must enter the correct code before they can view the page. After passing, the same browser usually skips re-entry for a while; updating or clearing the code forces re-verification. How it works:   1. From a card’s menu in Pages, click “Access Code”, enter a code, and save. Protection takes effect immediately; previously verified visitors are also forced to re-verify.   2. A visitor opens the domain and sees the code-entry form.   3. After entering the correct code, the same browser skips re-entry for a period.   4. To turn it off, open the dialog again, click “Clear”, and confirm. Previously verified visitors lose their bypass. Constraints:

• Codes are stored encrypted; the platform doesn’t keep plaintext. If forgotten, set a new one.
• The code protects the entire site—you can’t protect only part of it. After verification, the visitor lands on the site’s homepage, not the specific URL they originally opened.
• Any set / update / clear action invalidates every previously verified visitor’s bypass; their next visit requires the code again.

Database (Dynamic Pages Only) A dynamic page can have one platform-managed, dedicated MySQL database for storing form submissions, user records, and other dynamic content. The site reads and writes it automatically—no connection details to manage. Key usage:

• The database is attached by the agent when creating the site, or attached later to an existing dynamic site. The Pages page itself does not provide an entry to attach, inspect, or manage the database. Once ready, the next publish onward, the site can save and read data automatically.
• Pages does not yet offer a UI to inspect or edit database contents. To view raw data, ask the agent in chat.

Constraints:

• One database per site max; once attached, it can’t be detached or swapped.
• The database is released with the site—deleting the site truly wipes its data (see Taking Down).

​

Managing Pages

In the Pages entry, for each site you can:                                                                                          

• Check status and the latest publish time.
• Open the site’s domain link.
• Rename the site or Switch Version.
• Set / update / clear the Access Code.
• Bind a Custom Domain.
• Delete the site.
• View the current 30-day window’s request count and bandwidth usage per site. The account-wide total page count and quota are shown at the top of the page.

Note: The Pages entry doesn’t create new sites directly—new sites are created via the agent in chat. Editable Items

• Site name (card menu → Rename) — Takes effect immediately. Display-only; doesn’t change the domain or affect access.
• Access code (card menu → Access Code, published sites only) — Takes effect immediately. See Access Code Protection above.
• Current published version (card menu → Switch Version) — Takes effect immediately. Static sites switch in seconds; dynamic visitors don’t drop during the switch.
• Custom domain binding (card menu → Custom Domain) — Effective timing varies (see Custom Domain above). Default-domain access is unaffected.

Non-Editable Items

• Site type (static / dynamic) cannot be changed after creation.
• The platform-assigned default domain cannot be changed; to use your own, bind a custom domain.
• A published version cannot be modified in place—even a single text tweak ships as a new version.

​

Taking Down a Page

“Making a site no longer publicly available” has two cases: user-initiated deletion (permanent and unrecoverable), and platform-imposed suspension (access is blocked but the site itself is preserved; access resumes once conditions are met). User-Initiated Deletion Delete a site — From a card’s menu in Pages, click “Delete” and confirm. The platform cleans up the domain, custom domain, database, and all related resources; the site disappears from the list. Not recoverable. Important. Deletion truly releases the database—data cannot be recovered. To preserve database contents, ask the agent in chat to export them first. Platform-Imposed Suspension   Usage-cap suspension

• Trigger: Monthly request count or bandwidth hits the subscription cap.
• Effect: Visitors see a “Quota exhausted” page; site content, settings, versions, and database are all preserved.
• Recover: Per-site usage resets on a 30-day cycle; you can also upgrade the subscription to lift it immediately.

Downgrade over-quota suspension

• Trigger: After downgrading from a higher tier, the page count exceeds the new tier’s limit.
• Effect: The excess sites are suspended and cannot publish new versions; the databases themselves are preserved.
• Recover: Upgrade back, or delete other sites to free up the quota.

​

Plans, Quotas, and Limits

Pages is available on all tiers (Free / Plus / Super / Pro / Team Plus). Common to all tiers:

• Per-publish content size: 1 GB 

Per-tier limits: Pages is capped by site count, monthly requests, and bandwidth from your plan. Requests are not billed per-call in Credits—going over the quota triggers an automatic suspension rather than overage charges.

​

FAQs

Q: Visiting the domain shows a “Site deploying” page (503). A: The site exists but the instance isn’t ready to respond yet. Common cases:

• Tens of seconds to 1–2 minutes after the first publish of a new site, while the entry is still propagating.
• Cold start for a dynamic site after long inactivity—the platform needs to wake the backend, usually a few to a dozen seconds.
• The brief moment during a version switch when the old version goes down and the new one takes over. 

Check the site’s status on the Pages page. If it shows “Published” but visitors still see the deploying screen, try again shortly. Q: Visiting the domain shows a “Site unavailable” page (403). A: The domain is temporarily blocked. Common cases:

• This month’s request count or bandwidth has hit the subscription cap—usage resets on a 30-day cycle, or upgrade to restore immediately.
• After a tier downgrade, the account’s site count exceeds the new tier—upgrade back or delete other sites to free up quota. 
• After a tier downgrade, the Custom Domain entitlement was lost—the custom domain is suspended, but the platform-assigned *.mule.page default domain still works.  

Q: After a suspension is lifted, do I need to republish? A: No. Suspension only blocks the access entry; site content, versions, and database are fully preserved and immediately accessible again. However, if the suspension was caused by a tier downgrade where the new tier no longer includes the relevant entitlements: the site’s access code is removed, and the custom domain is suspended (the platform-assigned *.mule.page default domain is unaffected). Q: Can I batch-manage multiple sites (e.g., set the same access code on a bunch at once)? A: Not yet—sites can only be managed individually.