Pages

​

Overview

MuleRun Pages is the website-hosting service built into the MuleRun platform. Without provisioning servers, domains, CDN, or databases, users (or the super agent acting on their behalf) can publish a static site—or a dynamic one with forms, data storage, and third-party integrations—to the public internet, accessible via a platform-assigned default domain (e.g., xxx.mule.page) or the user’s own domain. Pages offers two entry points:                                                                                                          

• The “Pages” entry in MuleRun Chat’s left navigation: Lists every site under the account as cards, each showing a preview thumbnail, status, current version, domain link, and a management menu (see Managing Pages below).
• Direct publishing by the super agent in chat: The user describes a need, and the agent handles creation and publishing without ever leaving chat.

Capabilities:

• One-click publishing of pages or apps with forms, data, and third-party service integrations.
• Version history per site—roll back to any previous version with one click if a new release isn’t right.
• Auto-assigned *.mule.page default domain; paid users can bind their own domain by following the DNS prompts, with certificates and CDN provisioned automatically.
• An optional dedicated database for dynamic pages—reads and writes happen automatically, with no connection management needed.
• Per-site monthly request and bandwidth quotas controlled by subscription tier, with usage shown on each card.
• Basic management actions like rename and delete.

​

Target Users

​

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

The shortest path to “publish a static page via super agent in chat”:                                               1. Describe what you need in MuleRun chat, e.g., “Help me build a personal résumé page.”   2. The agent prepares the page content and previews it in chat.   3. Confirm and click Publish; the agent automatically creates a Pages site.   4. The platform assigns a default domain (e.g., a1b2c3d4.mule.page) and completes deployment.   5. Once published, an accessible link appears in chat.   6. Click the link to access the webpage in your browser; the new page also appears under the Pages entry in the left navigation for management. Once complete, a “Page Published” card should appear in chat. If it stays stuck on “Deploying” for a long time, refer to the corresponding entry in the FAQ below.

​

Detailed Guide

1. Publish a Page Create a Page Pages supports two types of pages:

• Static pages — Suitable for pure front-end display: personal homepages, portfolios, marketing pages, documentation sites, single-page apps, etc. More stable load times.
• Dynamic pages — Suitable for scenarios needing form handling, data storage, or calls to other services. Currently only supports Node.js backends, and the agent generates code accordingly; more backend languages will be supported over time.

Page type is determined at creation and cannot be switched online afterward—switching types requires creating a new page. Steps:     1. Tell the agent in chat which type of page to create (static or dynamic); for dynamic pages, optionally choose whether to also mount a database. If the account has reached the page count limit, an upgrade prompt will appear.   2. The platform assigns a *.mule.page default domain and creates the page. The new page appears in the right-side preview in chat and synchronously shows up on the /pages page.   3. If “Mount Database” was selected, the platform begins preparing an independent database for the page. The page cannot be published until the database is ready; the agent will retry shortly. Constraints:

• When renaming on the Pages page, names only support lowercase letters, digits, and hyphens (-), with a max of 30 characters.
• After creation, the page is not yet accessible—it only goes live after the agent completes the first publish.

Publish a New Version & Roll Back Each page preserves every publish result through “versions”—each time the agent publishes based on user changes, a new version is created, and all published versions are kept, allowing one-click rollback at any time.

• New publish — Tell the agent your changes in chat to trigger a new version publish. Once published, the page card’s status changes from “Deploying” to “Published”; visitors aren’t disconnected during the switch, though the first access right after switching may be slightly slower. If a publish fails (e.g., issues with agent-generated content), the card will show a “Failed” status—ask the agent to fix it and republish.
• Roll back to an older version — Click Switch Version in the card menu on the Pages entry, pick a historical version, and submit. No need to republish.

Constraint: A page only displays the currently published version externally; other versions are preserved and can be switched back to at any time. 2. Custom Domain   Pages assigns each page a *.mule.page default domain by default. Paid users can also bind a custom domain (e.g., www.mybrand.com); the platform automatically handles certificates and CDN integration. Steps:   1. Click Custom Domain in the card menu on /pages, and enter the domain to bind—proceed to the next configuration step.   2. The dialog’s second step shows the CNAME record to add at your DNS provider (including Type / Name / Value, with Proxy set to Disabled). Follow the prompts to copy and complete configuration—the platform begins issuing the certificate and verifying access.   3. Once DNS resolution and platform verification complete in sequence, visitors can access the page via the new domain. The card link displays the custom domain. Constraints:

• A page can only bind one custom domain; multi-domain binding is not yet supported in the Individual version. The /pages page currently only supports initial binding—no unbinding or domain-replacement entry after binding.
• The custom domain and default domain point to the same page, sharing the same access code and quota.
• After binding submission, the card immediately shows the custom domain, but actual accessibility depends on DNS resolution and platform verification readiness—a window of a few to about ten-plus minutes may pass where the link is shown but temporarily inaccessible.

3. Access Code Protection After setting an access code, visitors must enter the correct code to enter the page. Once verified, visitors typically don’t need to re-enter for a period of time; if the page owner updates or clears the access code, re-verification is required. Steps:     1. Click Access Code in the card menu on the Pages entry, enter a code in the pop-up window, and save. Access code protection is enabled immediately; previously verified visitors are also forced to re-verify.   2. The visitor accesses the domain and sees the access code input form.   3. The visitor enters the correct access code; the same browser doesn’t need to re-enter for a period of time afterward.   4. To disable access code protection, open the window again, click Clear, and confirm twice. Protection is disabled; previously verified visitors also lose their “no re-entry needed” status. Constraints:

• Access codes are stored in encrypted form; the platform doesn’t retain plaintext, so they must be reset if forgotten.
• The access code applies to all content under the page—it cannot protect only part of the site. After verification, visitors return to the site homepage, not the specific page they originally opened.
• Any setting / update / clearing causes all previously verified visitors to lose their “no re-entry needed” status—they’ll need to re-enter the access code on their next visit.

4. Database (Dynamic Pages Only) Dynamic pages can have an independent MySQL database hosted by the platform, used to save form data, user records, and other dynamic content. The page can read and write this database automatically, with no connection info to manage. Main usage:

• The database is mounted by the agent during page creation, or mounted onto an existing dynamic page. The /pages page itself does not provide entries for mounting, viewing, or managing the database. Once the database is ready, the page can automatically save and read data from the next publish onward.
• Pages does not currently provide an interface for viewing or editing database contents; to view data directly, ask the agent for help in chat.

Constraints:

• Each page can mount at most one database. Once mounted, it cannot be unmounted or rebound.
• The database is released along with the page—deleting the page actually clears all data within it (see “Take Down a Page”).

5. Manage Pages In the Pages entry, you can perform the following on each page:

• View page status and the most recent publish time.
• Open the domain link corresponding to the page.
• Rename the page; Switch Version of the published version.
• Set / update / clear Access Code.
• Bind Custom Domain.
• Delete the page.
• View current 30-day-cycle visit count and traffic usage for each page; the account’s current total page count and quota are shown at the top of the page.

Note: The Pages entry cannot directly create new pages—new pages are created by the agent in chat. Effects of each editing action:  

• Page name (card menu → Rename) — Takes effect immediately. Only affects display; doesn’t change the domain or affect access.
• Access code (card menu → Access Code, available for published pages only) — Takes effect immediately. See “Access Code Protection” above.
• Currently published version (card menu → Switch Version) — Takes effect immediately. Static pages take a few seconds; dynamic page visitors aren’t disconnected during the switch.
• Custom domain binding (card menu → Custom Domain) — See “Custom Domain” above. Doesn’t affect default domain access.

Non-editable items:

• Page type (static / dynamic) cannot be changed after creation.
• The platform-assigned default domain cannot be changed; to use your own domain, bind a custom domain.
• Published versions cannot be modified in place—even when the agent wants to “change one piece of text,” it goes live as a new version.

6. Take Down a Page “Making a page no longer publicly available” falls into two cases: active deletion by the user (permanent and unrecoverable), and passive suspension by the platform (access is blocked, but the page itself is preserved, and access resumes once conditions are met). Active Deletion:  

• Delete a single page — Click Delete in the card menu on the Pages entry and confirm twice. The platform cleans up the domain, custom domain, database, and all related resources; the page disappears from the list. Not recoverable.

Important constraint: Deletion actually releases the database, which cannot be recovered. To preserve database data, ask the agent in chat to help export it first. Passive Suspension:

• Usage limit suspension — Triggered when monthly visits or traffic hit the subscription limit. Visitors see a “Quota Exhausted” page; page content, settings, versions, and database are all preserved. Each page’s usage resets on a 30-day cycle; can also be lifted immediately by upgrading the subscription.
• Downgrade over-quota suspension — Triggered when downgrading from a higher tier to a lower one and the page count exceeds the new tier. Excess pages are suspended and cannot continue publishing or creating new versions; database itself is preserved. Resolve by upgrading back to the original tier, or actively deleting other pages to free up quota.

​

Plans, Quotas, and Limits

Pages is available on all tiers (Free / Plus / Super / Pro / Team Plus). Pages is controlled by the page count, monthly visits, and traffic quotas in your plan; it does not deduct Credits per visit—exceeding limits triggers automatic suspension rather than per-usage billing.

​

FAQs

Q: A “Page Deploying” prompt (503) appears when I access the domain. Why? A: This means the page itself exists, but the current instance isn’t ready to respond yet. Common cases:

• The first 30 seconds to 1–2 minutes after a new page’s first publish—the page entry is still taking effect.
• Dynamic page cold start—when first opened after a long period of no visits, the platform needs to bring up the backend, usually taking a few to about ten-plus seconds.
• The brief window during a version switch when the old version goes down and the new version takes over.

You can check the page’s status on the /pages page. If the status is already “Published” but access still prompts deploying, retry later. Q: A “Page Unavailable” prompt (403) appears when I access the domain. Why? A: This means the domain is temporarily blocked. Common cases:

• The page’s monthly visits or traffic has hit the subscription limit—usage resets on a 30-day cycle, or you can upgrade the subscription to restore access immediately.
• After a subscription downgrade, the page count under the account exceeds the new tier and excess pages are suspended—upgrade back or actively delete other pages to free up quota.
• After a subscription downgrade, “Custom Domain” entitlement is lost—the custom domain is suspended, but the platform-assigned *.mule.page default domain is still accessible.

Q: After being suspended and access is restored, do I need to republish? A: No. Suspension only blocks the access entry; page content, versions, and database are fully preserved—access works directly once restored. However, if the suspension was caused by a subscription downgrade and the new tier no longer includes the relevant entitlements: the page’s access code will be removed, and the custom domain will be suspended (the platform-assigned *.mule.page default domain is unaffected). Q: Can I batch-manage multiple pages (e.g., uniformly changing the access code for a batch of pages)? A: Batch operations are not currently supported—management is per individual page only.