Manus Shutdown Will Take Customer Websites and Apps Offline

The Manus shutdown begins August 23, 2026 for affected customers, and anyone hosting a real website, app, or service through Manus should take it seriously. Manus is telling affected users to back up their data before parts of it are deleted, wait while the service and affected hosted projects become unavailable, then return and restore their accounts and work themselves.

Affected users have until 7:59 a.m. SGT on August 23 to complete the backups they need. Manus begins deleting affected data at 8:00 a.m. SGT and says the deletion period continues through 7:59 a.m. on August 25. During that period, affected users will not be able to access Manus.

The restoration portal opens at 8:00 a.m. SGT on August 25, but that does not automatically restore anything. Customers still have to bring their backups back to Manus and restore the affected account and task data themselves. Some customers have to restore the actual Manus account first before they can even begin restoring their projects.

This is happening because Manus is returning to independent operation after its deal with Meta fell apart. I wrote about Meta cutting ties with Manus in June after China ordered the roughly $2 billion acquisition unwound and Meta began separating Manus from its systems. The mess around that deal is now reaching customers who trusted Manus with actual work.

If you only used Manus for disposable tasks, the shutdown may not affect much. I would look at this very differently if I had customers using a website or app hosted there, especially because Manus has confirmed that affected deployed websites can remain offline until their owners manually restore them.

Manus-Hosted Websites and Apps Will Go Offline

Manus says affected deployed websites become inaccessible at 8:00 a.m. SGT on August 23. Visitors can receive a maintenance page and normal website paths can return HTTP 503 Service Unavailable. Custom domains connected to affected Manus projects are included, so putting your own domain in front of a Manus app does not protect it from the outage.

The company explains the process in its WebDev service change documentation. One of the most important details is that Manus-hosted websites do not automatically come back when the deletion period ends.

They remain unavailable until the owner actively restores the Task Data Backup.

That makes the outage longer than a simple two-day maintenance window for anyone who does not restore immediately. Restore the project as soon as the portal opens and the downtime may stay close to two days. Restore it the following day and the site can remain offline longer. If the owner is away, misses the notices, loses the backup, or runs into trouble restoring it, Manus says there is no fixed date when the affected website has to come back online.

For something running in production, that is a serious problem. Manus has encouraged people to build and deploy real software through WebDev, connect custom domains, use databases, add authentication, connect outside services, and rely on its infrastructure. Those customers now have to plan around an outage caused by what happened to Manus itself.

The disruption can also reach beyond the page people see in a browser. Manus says affected projects can lose access to authentication, uploads, APIs, built-in AI functions, maps, databases, synchronization processes, and other services that depend on Manus infrastructure.

WebDev schedules that should run during the shutdown can fail, and Manus says missed schedule runs will not be replayed afterward. Webhooks sent to an unavailable Manus-hosted service can return a 5xx response, and Manus does not queue those failed webhook events for later delivery.

If an app receives payment events, form submissions, automated updates, account activity, or other outside requests, I would find out what happens when Manus stops accepting them. Some outside services retry failed webhooks on their own, but that depends on the service. Manus is telling customers not to expect Manus to preserve and replay them.

Cloud Computers are affected too. Manus says affected Cloud Computer instances stop running during the deletion period. Public addresses, running processes, web services, certificates, firewall rules, and anything depending on those instances become unavailable until the related data is restored.

Files stored directly in a Cloud Computer filesystem need extra attention because Manus says they are not included in the normal Task Data Backup. Anyone storing something important there should download those files separately before the shutdown.

Back Up Your Manus Data Before August 23

Manus has divided affected customers into different categories, and the backup requirements depend on which type of account you have. The company provides the process in its data backup guide.

Type A and Type B users can keep the account itself, but affected task data still needs to be backed up if they want to restore it after the deletion period.

Type C users have more to deal with because Manus says their account information is also within the deletion scope. Those users need an Account Info Backup to restore the account before they can log in and restore their Task Data.

The Task Data Backup can include tasks, generated files, websites, and project configuration. Manus says the backup can range from tens of megabytes to tens of gigabytes depending on how much the account contains. Individual backup packages are limited to 4 GB, so larger accounts can end up with several files that all need to be saved correctly.

The backup only captures the account as it exists when the backup is generated. If you back up today and continue working tomorrow, the new work is not automatically added to the old backup. Manus tells users to create another backup before the deadline when important changes are made afterward.

I would check the actual destination after every backup. Manus tells customers to make sure the exported packages really exist in their cloud storage or local folder, and it warns users not to modify or rename the files because doing so can make them unusable for restoration.

If the project matters, keep another copy somewhere you control. I would not let the only recovery package for a production project sit in one place while the company that generated it is preparing to delete the original data.

Team accounts need their own attention. Only the team owner can perform the team backup and restoration. Team members cannot restore the team workspace themselves. If the owner’s personal account is also affected, the owner may have to restore the personal account, then the team account, then the team data.

Restoration Can Only Be Completed Once

The restoration process is another part I would not rush through. Manus says data restoration can only be completed once.

The company’s restoration guide allows multiple backup packages to be uploaded during that process, and Manus says it will deduplicate and consolidate their contents. Customers are still responsible for making sure they have the correct and most recent backup files before finishing the restoration.

Type A and Type B users can log in and restore their Task Data. Type C users first need to restore the deleted Manus account using the Account Info Backup, log back into that account, and then restore the Task Data.

Manus says previously deployed websites should come back online automatically after the Task Data Backup is restored. I would still test everything before treating a production app as recovered.

Manus itself tells customers to verify databases, stored files, environment variables, application keys, domains, DNS, HTTPS, authentication, external APIs, webhooks, scheduled tasks, connectors, and other important parts of the application. Some third-party connectors need to be turned back on manually and some outside services may require another authorization.

If the app handles payments, user accounts, uploads, forms, email, or customer data, test those features directly. A homepage loading successfully does not tell you whether the rest of the application came back correctly.

Custom domains can also need time for HTTPS to recover if Manus has to issue another certificate after restoration. That can extend the real recovery time even after the project itself appears online.

What I Would Do Before the Manus Shutdown

If Manus told you that your account is affected, I would deal with it now instead of waiting until the final hours.

• Open the official Manus Backup Tool and check exactly which account and data are affected.
• If you are a Type C user, save the Account Info Backup you need to restore the deleted account.
• Create a complete Task Data Backup and verify that every package actually exists after the export finishes.
• Back up again before the deadline if you continue changing important projects.
• Keep another copy of important backup files somewhere outside Manus.
• Download important Cloud Computer filesystem files separately because they are not included in the normal Task Data Backup.
• Export the project source code to GitHub or another repository when possible.
• Document the databases, domains, APIs, authentication services, payment systems, webhooks, storage, email services, scheduled jobs, and other outside dependencies the project uses.
• If customers depend on the project, consider hosting your own maintenance or status page outside Manus before the outage begins.
• After restoration, test the application like a production deployment instead of assuming the backup brought everything back correctly.

A GitHub export is useful, but it does not replace the Manus backup. Source code alone may not include the hosted database, uploaded files, configuration, environment information, scheduled processes, or other services the application uses. I would still want the source code outside Manus because there is no good reason for Manus to hold the only copy of something I built.

I Would Move Important Apps Away From Manus

I would not try to rebuild a complicated production application somewhere else overnight without understanding what is inside it first. Moving the visible website can be easy while the database, authentication, uploads, API routes, scheduled jobs, and other important parts are still tied to Manus.

I also would not put an important application back into the same position after this is over.

Railway would be one of the first places I would look for a normal full-stack application. It is built around running application services, databases, workers, and other parts of a software project without requiring the AI tool that created the project to remain responsible for hosting it.

Render is another service I would consider for web applications, APIs, background workers, databases, and related services. For many Manus projects, either Railway or Render makes more sense to me than leaving production tied permanently to an AI builder that is currently telling customers to download backups before their hosted work disappears.

A normal VPS or cloud server is still a good option for people who know how to manage one or have someone who does. It requires more work, but that extra control can be worth it for anything important. The source, database, backups, configuration, and recovery process can be managed separately instead of being bundled into one AI platform.

I would not recommend moving an important Manus project to Vercel simply because a lot of AI-generated Next.js projects end up there. I already covered the Vercel data breach and the Context.ai compromise connected to the incident, and I already have my own reasons not to trust Vercel with something important.

The migration also needs to include more than the frontend. Find out where the database lives, how users authenticate, where uploaded files are stored, what environment variables the project needs, which APIs it calls, what external services send webhooks into the application, and whether anything scheduled inside Manus still needs to be rebuilt somewhere else.

I have used Manus since early in the product’s life and already do not trust it with important production work. I have dealt with wasted credits, ignored instructions, billing problems, refund problems, and Manus making changes I never asked it to make. The Manus shutdown adds another problem that has nothing to do with whether the agent can write code correctly.

Customers paid Manus, spent credits building projects, deployed websites and apps, connected custom domains, and trusted the company to keep those projects available. Some of those customers are now being told to save their own recovery files before Manus deletes the underlying data and takes their hosted projects offline.

The collapse of the Meta deal explains why Manus is going through this transition, but it does not make the customer experience any less ridiculous. Affected users have to make the backups correctly, keep them safe, wait through the shutdown, restore the right account and project data, and then check whether the application survived the process properly.

If Manus is useful for creating something, use it for that. I would keep the production application, source code, backups, important data, and recovery plan somewhere that does not depend entirely on Manus remaining available.

The Manus shutdown begins August 23. Anyone with an affected account should finish the backups before the deadline, and anyone running an important Manus-hosted website or app should already have a plan for the outage and what happens afterward.